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

Custom module loader for Workers #21667

Closed
rumkin opened this issue Jul 5, 2018 · 5 comments
Closed

Custom module loader for Workers #21667

rumkin opened this issue Jul 5, 2018 · 5 comments
Labels
esm Issues and PRs related to the ECMAScript Modules implementation. feature request Issues that request new features to be added to Node.js. stale worker Issues and PRs related to Worker support.

Comments

@rumkin
Copy link
Contributor

rumkin commented Jul 5, 2018

Node.js users has two problems:

  • Simple and powerful sandboxing.
  • Using ES modules.

Workers can solve both of them in very elegant way with custom resolvers which are the same as experimental es module resolver.

const worker = new Worker('./worker-path.js', {
    moduleLoader: {resolve, dynamicInstantiate},
});

It solves sandboxing with full dependency control in custom context. And it simplifies es modules usage with preserving usual code flow in main thread and es flow in worker thread.

/cc @addaleax @TimothyGu @Qard @aqrln @oe @benjamingr @nodejs/workers

@rumkin rumkin changed the title Worker custom module loader Custom module loader for Workers Jul 5, 2018
@devsnek devsnek added esm Issues and PRs related to the ECMAScript Modules implementation. worker Issues and PRs related to Worker support. labels Jul 5, 2018
@devsnek
Copy link
Member

devsnek commented Jul 5, 2018

/cc @nodejs/modules @nodejs/workers

@devsnek
Copy link
Member

devsnek commented Jul 5, 2018

@rumkin the overall idea sounds good but i think we need to wait a bit to figure out how loader hooks will behave in the future. there's a lot of movement with them at the moment.

@benjamingr
Copy link
Member

benjamingr commented Jul 6, 2018

I tend to agree with @devsnek in that I like the idea and think this is too early and it should be addressed once modules settle.

Mixing two experimental APIs means they each hinge on each other and cannot progress to stable unless progressing together - this sounds like an enhancement that can happen at a later point.

@github-actions
Copy link
Contributor

github-actions bot commented Mar 8, 2022

There has been no activity on this feature request for 5 months and it is unlikely to be implemented. It will be closed 6 months after the last non-automated comment.

For more information on how the project manages feature requests, please consult the feature request management document.

@github-actions github-actions bot added the stale label Mar 8, 2022
@github-actions
Copy link
Contributor

github-actions bot commented Apr 8, 2022

There has been no activity on this feature request and it is being closed. If you feel closing this issue is not the right thing to do, please leave a comment.

For more information on how the project manages feature requests, please consult the feature request management document.

@github-actions github-actions bot closed this as completed Apr 8, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
esm Issues and PRs related to the ECMAScript Modules implementation. feature request Issues that request new features to be added to Node.js. stale worker Issues and PRs related to Worker support.
Projects
None yet
Development

No branches or pull requests

4 participants