# Deno Worker Fix Explanation

## The Problem

The issue was that MQTT.js was incorrectly identifying Deno workers as
browser environments, which caused problems when trying to use TCP
connections. Here's what was happening:

1. **Original `isWebWorkerEnv()` logic**: The function was checking if
the environment was a Web Worker by looking for
`self?.constructor?.name?.includes('WorkerGlobalScope')`

2. **Deno Worker confusion**: In Deno workers, this condition was
returning `true` because Deno workers do have a `WorkerGlobalScope`-like
environment (`DedicatedWorkerGlobalScope` to be exact)

3. **Incorrect browser detection**: Since `isWebWorkerEnv()` returned
`true`, the overall `isBrowser` check also returned `true` (line 37:
`isBrowser = isStandardBrowserEnv() || isWebWorkerEnv() ||
isReactNativeEnv()`)

4. **TCP connection blocked**: When `isBrowser` was `true`, the MQTT
connection logic would force WebSocket connections (`ws://` or `wss://`)
and didn't allow TCP protocols (`mqtt://` or `mqtts://`)

## The Solution

By adding `typeof Deno === "undefined"` to the `isWebWorkerEnv()`
function, you're ensuring that:

- **Deno workers are NOT considered web workers**: The function now
returns `false` for Deno workers, even though they have a
`WorkerGlobalScope`-like environment
- **Real web workers still work**: Browser-based web workers don't have
`Deno` defined, so they still get detected correctly
- **TCP connections work in Deno**: Since `isBrowser` now returns
`false` for Deno workers, the connection logic allows TCP connections
(`mqtt://`, `mqtts://`) instead of forcing WebSocket connections

## Why This Matters

Deno workers need to be able to use TCP connections for MQTT because:
- They run in a server-like environment (not a browser)
- TCP connections are more efficient for MQTT than WebSocket connections
- The original browser detection was preventing legitimate TCP usage in
Deno

The fix ensures that Deno workers are treated as server environments
(like Node.js) rather than browser environments, allowing them to use
the appropriate connection method for MQTT protocols.

---------

Co-authored-by: Alex Sharikov <[email protected]>

Here the proxy stream is being written, so we need to check if it is
writable ("which means the stream has not been destroyed, errored, or
ended, see
https://nodejs.org/dist/v18.19.0/docs/api/stream.html#writablewritable
).

Fixes #1914

I could reproduce the 'stream.push() after EOF' error in an app, but
unfortunately have no idea how to use it for a reproduction. Hopefully
this patch provides enough inspiration to write a test.