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

[RFC] Parcel 2: Better node support #2493

Open
devongovett opened this issue Jan 1, 2019 · 12 comments
Open

[RFC] Parcel 2: Better node support #2493

devongovett opened this issue Jan 1, 2019 · 12 comments

Comments

@devongovett
Copy link
Member

devongovett commented Jan 1, 2019

Parcel 1 has a node target, but it is not super well baked. We should improve on it for Parcel 2 and make a great Node build experience for Parcel users.

  • Support native modules (.node) by copying them to the dist directory.
  • Finding these native modules (when using platform-dependent loading; e.g. sharp/lmdb or our own Rust-based transformers)
  • Copy statically analyzable files referenced by fs calls to the dist directory. We already have support for inlining fs calls for browser targets, but we currently don't do anything in Node. Rather than inlining, we can just copy them and let node read them at runtime.
  • Rewrite __dirname and __filename. Currently we don't do this for Node targets, but we probably should so that they refer to the source file rather than the dist.
  • Bundle node_modules by default? (not sure about this)
  • Support running bundled output inside node with a require hook (e.g. for tests), or running via the CLI (parcel-node?). See Parcel 2: @parcel/register node require hook #2396.
  • Make it possible to build Parcel with Parcel 🤯. We could even ship the Parcel CLI prebundled like this to improve startup time by avoiding require cost.

Related: #2492, #2396, #2345.

The zeit team have created ncc, which solves many of these issues. We should look at getting their integration tests running against Parcel as well.

Please comment with other suggestions for ways we can improve Node bundling in Parcel! 😄

cc. @rauchg @guybedford since you know about a lot of edge cases you've run into with ncc. 😉

@pocesar
Copy link
Contributor

pocesar commented Jan 31, 2019

just a feedback, tried to use parcel for serverless, didn't do too hot because the way parcel 1 greedily tries to take care of everything. bundle size with parcel: 13MB, bundle size with serverless-webpack: 31kb
i think that would be the main use

@mischnic
Copy link
Member

Are you talking about not bundling node_modules?

@pocesar
Copy link
Contributor

pocesar commented Jan 31, 2019

yes, selectively not bundling stuff (like aws-sdk that is already available in lambda, but many others), also failed for some modules like juice / mimer that tries to use fs.readFileSync using __dirname and fails

@RobertWHurst
Copy link
Contributor

It would also be great if you configure parcel to exclude node_modules, it still hooks require so it can rewrite imports based on aliases in the package json.

@brillout
Copy link

brillout commented Aug 8, 2019

Bundle node_modules by default?

Not bundling node_modules is dramatically faster, since user-written server code is typically much less LOC compared to all loaded node_modules code.

Why would someone want to transpile node_modules/ code?

@brillout
Copy link

brillout commented Aug 8, 2019

Why would someone want to transpile node_modules/ code?

As for bundling node_modules/, the only use case I can think of is having a slightly faster production code. As far as I see, it wouldn't be worth the increased building time.

@mischnic
Copy link
Member

mischnic commented Aug 8, 2019

The only difference is having a self contained JS file that starts up slightly faster.

@brillout
Copy link

brillout commented Aug 8, 2019

Ok I see -- so Parcel would only bundle node_modues/ for a production build. And while developing, node_modules/ would not get bundled. Sounds good.

@muratcorlu
Copy link

I'm also trying to use Parcel to bundle my AWS Lambda functions. Because of aws-sdk is globally provided in Lambda, normally I place it as a dev-dependency to not include it in production bundle. But with parcel, -probably because of I include it in my code- it includes whole aws-sdk to bundle and it add 8MB more code(minified) to bundle.

I think a config for excluding dependencies from bundle or not including devDependencies in the bundle even if it's imported, can be helpful.

@RamIdeas
Copy link

Just want to point out that #2934 was closed as a duplicate (of this issue? thanks @mischnic for point it out) but I don't see any mention of running the script when using parcel serve in the bullet points above.

It should be an easy addition, right? Maybe one open question is, if multiple entries are specified, should each one be run? And do all instances get restarted on any change?

@aminya
Copy link
Contributor

aminya commented Sep 26, 2020

Support native modules (.node) by copying them to the dist directory.

This is a matter of copying the built node files to the dist folder and update the URL. Can't we do it now?

Rewrite __dirname and __filename. Currently we don't do this for Node targets, but we probably should so that they refer to the source file rather than the dist.

I have created a separate issue for _dirname

@Shayan-To
Copy link

Any progress on this? I'm using express for a simple back-end server. Does Parcel provide HMR for express? I read in #355 that Parcel 1 had an express middleware. Is there something similar available for Parcel 2? Or is there another way to do it?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
No open projects
Parcel 2
  
To do
Development

No branches or pull requests

9 participants