Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

process polyfill is missing methods #33

Closed
Richienb opened this issue Nov 18, 2024 · 8 comments · Fixed by #34
Closed

process polyfill is missing methods #33

Richienb opened this issue Nov 18, 2024 · 8 comments · Fixed by #34

Comments

@Richienb
Copy link

Richienb commented Nov 18, 2024

I maintain a Webpack plugin node-polyfill-webpack-plugin that provides similar functionality to this module, but in a simpler, Webpack-only, interface.

Richienb/node-polyfill-webpack-plugin#58 notes that the process polyfill is missing process.platform and process.arch. This issue, among others also appears here but is unreported.

Instead of making the change only within my own plugin, maybe we could consolidate together into an org, such that I make polyfill improvements in this repo and then import the module into mine?

@niksy
Copy link
Owner

niksy commented Nov 18, 2024

There’s a mock implementation for browser environment, but I don’t know if that’s enough.

As for making changes and how to proceed, do you know the steps which would take to make this possible for all users of all respective modules? This module is used as dependancy in a lot of Vite plugins, and Webpack implementation is here but not as simple as dedicated plugin.

@devzzzero
Copy link

Hey guys, @niksy @Richienb

Thank you very much for your responses.

There doesn't seem to be anything to do immediately, but it really would be nice to have a some kind of jailbreak for webpack+electron-forge where process, fs, os, can be injected to the renderer side for projects like mine.

It's all kinds of hassles to jump through the existing IPC API that electron (recent versions, say 30.x onward) supplies to get communication to work between the main thread and the renderer.

It's actually worst than that because electronjs.org docs are apparently out of date (in the sense that their published examples for IPC don't work out of the box!) , not to mention, it slows things down by 2x or more.
All I want to do is to listen do another service (running on localhost on the machine that shoots out some logs and status messages and the like over zeromq) and render some blobs via electron.

The fact that zeromq/zeromq.js#676 can't be loaded up directly on the renderer side is just awful, due to missing fs etc...

I'm willing to do the heavy lifting to get a (new name alert) jailbreak-webpack-polyfill but need guidance on where to start.

Here is my first stab at a brainstorm for this (probably wrong, because I am a webpack n00b)

  1. grab a specific version of fs.js, process.js from electron, and somehow use the existing webpack API and inject them somehow on the renderer side.
  2. Somehow maintain a mapping between electron releases <---> { process, fs, os, ...}
  3. Conquer the world! (err ... lots of details missing here, obviously!!!)

Any tips or ideas you guys can throw my way would be great.
Thank you!

@Richienb
Copy link
Author

do you know the steps which would take to make this possible for all users of all respective modules

@niksy I'm thinking that so long as we continue isolating each polyfill in separate files/exports, I can just import and re-export them, passing them to Webpack.

There’s a mock implementation for browser environment, but I don’t know if that’s enough.

This is interesting, I missed it the first time I looked. I think I would like the platform/architecture info to be more specific, enough to be compliant with Node.js APIs.

@niksy
Copy link
Owner

niksy commented Nov 19, 2024

@Richienb also, have a look at proxy implemention for url and querystring: https://github.com/niksy/node-stdlib-browser/tree/master/proxy

The idea was to augment external modules with additional exports since those modules haven’t catch up with recent Node internals changes (see also defunctzombie/node-url#59 (comment))

Maybe this can also be done for process? Re-export with arch and platform additions? I think this would be best approach (no copy/paste, just reuse existing module, reduce potential code duplication by deduping external module, etc.), and then you can use it in Webpack plugin if you want.

As for org changes and future maintenance, I’m open to all suggestions. I’ve created this module soon as Webpack stopped active maintenance of their implementation and I’ve found out this is still really useful to a lot of developers.

@devzzzero
Copy link

Reading your sources... (take a few days)
Thanks again for your feedback @Richienb @niksy

@niksy
Copy link
Owner

niksy commented Nov 20, 2024

I’ve created PR where we can see if this is what’s needed for this issue to be resolved from this side.

niksy added a commit that referenced this issue Nov 20, 2024
niksy added a commit that referenced this issue Nov 20, 2024
niksy added a commit that referenced this issue Nov 20, 2024
niksy added a commit that referenced this issue Nov 20, 2024
niksy added a commit that referenced this issue Nov 21, 2024
niksy added a commit that referenced this issue Nov 21, 2024
niksy added a commit that referenced this issue Nov 21, 2024
@niksy niksy closed this as completed in #34 Nov 21, 2024
niksy added a commit that referenced this issue Nov 21, 2024
@niksy
Copy link
Owner

niksy commented Nov 21, 2024

Release as part of https://github.com/niksy/node-stdlib-browser/releases/tag/v1.3.0!

@devzzzero if you’re not using latest version of https://github.com/Richienb/node-polyfill-webpack-plugin, install it and you should get changes. If you already have it installed, reinstall it so minor version bump gets picked up.

@devzzzero
Copy link

Thank you @niksy !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants