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

Decision: Choose an NPM Integration Strategy #1610

Closed
dchambers opened this issue Nov 26, 2015 · 2 comments
Closed

Decision: Choose an NPM Integration Strategy #1610

dchambers opened this issue Nov 26, 2015 · 2 comments

Comments

@dchambers
Copy link
Contributor

We were originally going to integrate with NPM based on the BladeRunnerJS NPM Integration Strawman, which involved doing our bundling and using SystemJS as our module format. Then, we subsequently came to the conclusion that we could more quickly get something out there by relying on a third-party bundler to bundle a script that caused the various parts of the bundle to be made available via our current module system (browser-modules), as per the Alternative NPM Integration Strawman.

Unfortunately, this approach means that clients that don't want to or can't use NPM would be forced to bundle every part of every BRJS and CT library, effectively creating a hard dependency on Node.js since this is unlikely to be acceptable to anyone. While we could go back to the original approach, we've since realized that the alternate approach has some other advantages that are worth taking into consideration before we make a decision.

Here are the pertinent facts...

Bundle ourselves:

  1. No hard dependency on Node.js.
  2. Can only use System.js.
  3. No source maps.
  4. Requires more time (though we have a BRJS / SystemJS spike so some of the additional work is now done).
  5. System.js is a sizable dependency (additional 17.5KB when minified and gzipped — see these two comments).
  6. No slower than current bundling.

Use external bundler:

  1. Hard dependency on Node.js.
  2. Can use any bundler.
  3. Can use sourcemaps.
  4. Quicker to implement.
  5. Modules from Node.js bundle have to be re-exported using define() invocations, which adds additional size.
  6. Maybe slower because there are two bundlers, one of which requires a process to be spawned (e.g. ~1sec to bundle react & redux — use the bundle-all-spike to calculate your own figures).

So, which option would people prefer us to go with?

UPDATE: @trueadm suggested a third option which is better than the previous two. The idea here is to convert NPM libraries into a form that BRJS can already consume. Exactly how this would be done, and whether this can be done in a way that would still allow CSS and HTML templates to be required, etc, is still to be determined, but it seems like a promising idea.

Use NPM to BRJS conversion tool:

  1. No dependency on Node.js
  2. No bundler required.
  3. No sourcemap support.
  4. Quick to implement.
  5. No change to the bundled size.
  6. No change to the bundle creation speed.
@dchambers dchambers added this to the NPM Support Lite milestone Nov 26, 2015
@trueadm
Copy link

trueadm commented Nov 26, 2015

Personally, I'd much prefer to use an external bundler.

@dchambers
Copy link
Contributor Author

Assuming it can be made to work, we've decided to go with #1611 since it has no downsides, but still allows us to start migrating our libraries to NPM.

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

No branches or pull requests

2 participants