I am trying to use the JS agent from the browser and I get this:
ferenceError: global is not defined
at new Decoder (decoder.js:58:26)
at new Uint8ArrayDecoder (cbor.ts:105:1)
at decode3 (cbor.ts:121:19)
at HttpAgent.status (index.ts:528:17)
at async HttpAgent.fetchRootKey (index.ts:534:24)
This is just trying to do something simple like create an actor. It seems to me that the agent is expecting node polyfills. Why is this the case? It would be great if the agent did not assume a non-browser environment when in the browser, and if the polyfills were automatically included in the deployed npm package, instead of expecting the developer to provide these polyfills.
This goes back to a deeper issue I think which is that the agent seems far too dependent on assuming the user’s bundler (webpack), whereas other bundlers are used and in my case I am using Vite.
My main recommendation would be to deploy the library with the polyfilled libraries in the bundle, thus it doesn’t become a problem to the end developer, and you can hopefully go on simplifying that over time instead of passing the burden onto the end developer.
in this case, I’d really rather not do the polyfill though. it adds bloat and everyone already has a TextDecoder and TextEncoder in their environment. It’s just unfortunate that the library is pointing to a named global object and looking for it there instead of having fallback strategies we could take advantage of
While agnosticism always has merit, Vite is a thriving community of developers, and it’s tooling (“a dfx vite plugin”) could very well provide an on ramp to many a developer (particularly if coupled with Azle perhaps?).
Though globalThis seems to be the current consensus winner.
Incidentally, here’s the final remark on one of (of the several) Vite git issues on this subject:
@ljharb the mainstream tooling authors have reached the consensus that Node is no longer special - with Deno and worker
environments becoming more common, it’s just one of the many JS runtimes that build tools may target. Its platform-specific APIs should not get special treatment in general-purpose build tools, especially when the user is targeting browsers. JS packages published on npm are also no longer by definition Node-specific - if a package is meant to be usable in the browser, then it is the package authors’ responsibility to ensure their code can run properly in the browser without special treatment.
You may disagree with that and that’s fine - but your opinion really doesn’t matter here, because the ecosystem moves forward as a result of the natural selection process of its users. If not supporting Node built-ins is a mistake, surely fewer users would use tools that don’t support them (including Vite and webpack 5), and those tools should die out in the long run. If users turn out to still opt for these tools, then it means to them the utility these tools provide are more important than the occasional minor inconvenience, and in turn they would request the package authors to properly ship universal packages (instead of relying on Node APIs as if it is available in all JS environments). That’s how we shed the collective technical debt and move the ecosystem forward, and it’s 100% an intentional decision in Vite’s design to push it towards that direction.