fix: circumvent issues with ESM process polyfills

[WasabiThumb]

Would resolve #539. This is a hacky solution that may preferrably be made obsolete by resolution of davidmyersdev/vite-plugin-node-polyfills#106.

The root issue is that some node:process polyfills export an ES module that is not unwrapped at runtime. This change would introduce a patch that conditionally unwraps the module in the event that checks pass indicating that it is wrapped. Those checks are:

• require("node:process")["__esModule"] === true
  • Intent is to quickly eliminate false positives
• "nextTick" in require("node:process")["default"] || "nextTick" in require("node:process")["process"]
  • Indicates that the default or process property of the import is indeed intended to polyfill node:process. The choice of nextTick here is arbitrary, however the method would be required for proper function of this package.

This also inherits the curiosity introduced by #497 where node:process is imported via process/.

[mcollina]

Thanks for opening a PR! Can you please add a unit test?

[WasabiThumb]

Thanks for opening a PR! Can you please add a unit test?

Sorry for the delay! I've added the task test:vite. It was very painful to replicate the correct setup, but it works like a charm in the end. It's not as graceful as the other browser tests, mostly because I couldn't get playwright working on Arch, but I believe this is a decent starting point. Specifically, the use of ViteDevServer.openBrowser() instead of playwright may not play well with CI. However, IPC is performed using an endpoint on the dev server rather than console stdout; therefore migration should be easy for those that can get playwright to run should that be desired. On the other hand, the need to test multiple browsers is currently met by the rollup suite.

Example output:

[WasabiThumb]

This is strange- despite using the reprex as a reference, the test does not break when commenting out the patching functionality of the shim introduced by this PR. It's possible that the issue only crops up when the Vite source is TypeScript, since that's the only obvious difference. I may have to consider updating the test to use TypeScript- or perhaps throw this all out and consider it a TypeScript issue.

EDIT: Or maybe Vite is caching the version of readable-stream with the patch uncommented? I'm not sure how to test this rigorously- but it does make sense for it to make that sort of optimization, and we're not telling it to invalidate this cache (if it exists). 🤔🤔🤔 Perhaps those following at home can try this with an untainted environment.

EDIT 2: Made the apparent version change randomly from run to run in an attempt to bust any caches that may exist; same behavior.

[gsantiago]

@WasabiThumb any update?

[WasabiThumb]

@WasabiThumb any update?

Moving this along would require writing a test that would actually fail without the fix, perhaps by converting the existing test's Vite source to TypeScript as that is a likely component of this issue and seems to be present whenever it's reported. Since I'm not actively developing the project in which I ran into this issue right now, it might be a while until I am able to do that myself. If you want to get ahead of it, you can fork my repo and PR a test/modify the existing test such that it demonstrates this behavior; then I'll happily resolve the conflicts and request a review.

[mesqueeb]

@mcollina isn't there any way you can alleviate the blockage of this PR. readable-stream doesn't work with vite based esm builds...

[mcollina]

I have no time to volunteer to work on a comprehensive test suite for this bug. Without it, we'll keep releasing versions after versions to chase all the different tool combinations. If you are writing on behalf of a company and would like to sponsor this work, ping me via email.

[mesqueeb]

@mcollina can't you just release it as a beta version? no need for the test suite, I can test the beta version in my app directly.

[MattiasBuelens]

@mesqueeb You can always fork the package, or use something like patch-package to apply patches directly to the readable-stream code inside your node_modules.

Or even better, since you apparently ran into this issue yourself: try to make a minimal reproduction case that we can use for the test! 😉 As you can read in the thread, we're struggling to make a good test for this, so any help with that would be appreciated.