`process` polyfill is missing methods

[Richienb]

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]

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]

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]

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]

@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]

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

[niksy]

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