[Bug]: bundler hard code navigator in mqtt.esm

[EmixamPP]

MQTTjs Version

5.8.0

Broker

mosquitto

Environment

Browser

Description

The variable navigator, used to determine some env, like tkiki.js #1895, is replaced by a content determined at bundle time, namely: P={deviceMemory:8,hardwareConcurrency:8,language:"en-US"} if you look at mqtt/dist/mqtt.esm. And because of that, it is impossible to determine the runtime using this technique (thus the WebSocket lib choice is wrong).

Minimal Reproduction

1. Open mqtt/dist/mqtt.esm
2. Search for txiki.js and see that the code from feat: add compatibility with txiki.js #1895, navigator.userAgent==="txiki.js" has been transformed in P.userAgent==="txiki.js"
3. Search for P= and see that the value assigned is P={deviceMemory:8,hardwareConcurrency:8,language:"en-US"}
4. Can be confirmed at runtime by adding console.log(P)&& before P.userAgent==="txiki.js"

Debug logs

[robertsLando]

Would you like to submit a PR to fix this issue?

[EmixamPP]

After investigation, the issue is because of

MQTT.js/esbuild.js

Line 31 in 11bb9bd

navigator: true, // Needed for WeChat, ref #1789

from

MQTT.js/esbuild.js

Lines 20 to 33 in 11bb9bd

	plugins: [
	polyfillNode({
	polyfills: [
	'readable-stream'
	],
	globals: {
	global: false,
	__dirname: false,
	__filename: false,
	buffer: true,
	process: true,
	navigator: true, // Needed for WeChat, ref #1789
	}
	}),

If I remove that line, navigator is untouched, and so it works as expected, but I guess I cannot PR that because of #1789.

[robertsLando]

Wondering if we can have a different solution for wechat, maybe if they add a navigator polifilly before importing mqtt it could work?

[EmixamPP]

So if I understand correctly, you're not against a PR that removes out-of-the-box support for WeChat?

Here is what I propose:
I could PR something similar to what is proposed in #1900 or the current timeVariant option, with a new forceNativeWebSocket option, that will by-pass the automatic IS_BROWSER call. (Consequently, I will need to move the import of the modules inside the connect function).
You do not need to extend the isBrowser function anymore, you could just support standard browser page, webworker and NodeJS detection, and if it is not good for the others envs, they can use that option.

Advantage/Disadvantage:
- Yet another option specific to underlying implementation in the constructor
+ Support all the env that support native WS. Even for users that are under Node 21 and do not want ws (?)
-+ Remove backward automatic compatibility for React Native may not be what you want, so maybe I could just remove txiki.js from isBroswer, then you could "refuse" niche runtime/envs (I understand it can be difficult...)

Let me know if you think it is valuable for the project, or any other idea; I would be happy to make a PR that would allow to easily support all runtime/envs that have native WebSocket support.

[robertsLando]

So if I understand correctly, you're not against a PR that removes out-of-the-box support for WeChat?

Yeah I'm not, they already have to import some polifilly: https://github.com/mqttjs/MQTT.js#wechat-and-ali-mini-program-support

I'm ok with all implementatins that do not break existing things (except the one about wechat I mentioned above)