Parcel: Multi-compiler mode — output multiple bundles

[ivancuric]

It would be great if parcel supported multiple targets, preferably using using a browserslist file.
For instance:

[modern]
last 1 Chrome versions
last 1 Firefox versions

[legacy]
last 2 version
not ie < 11
> 2%

Tools in the pipeline that support it like babel-preset-env and postcss (primarily autoprefixer) should use it as well.

The output should be two completely separate builds. The modern one with only the neccessary transpilation (would a target of chrome 63 still bundle files?), and the legacy one which has babel-polyfill, whatwg-fetch and regenerator-runtime injected, plus all the ES5 transpilation.

Optionally, parcel should output an ES5 compliant snippet of code which could be either output as an entry.js file or placed inline. The snippet would use feature detection to asynchronously load the required bundles. For example:

(function() {
  try {
    new Function('async () => {}')();
  } catch (error) {
    // create script tag pointing to legacy-bundle.js;
    return;
  }
  // create script tag pointing to modern-bundle.js;;
})();

Using <script type="module"> for feature detection is not recommended.

As for selective async loading of CSS, I'm not sure if it's worth it.

[jamiebuilds]

Wouldn't it be simpler just to run parcel twice with different environment configurations?

We do this a lot on my team:

BABEL_ENV="production:modern" yarn run ...
BABEL_ENV="production:legacy" yarn run ...

```js
// .babelrc
{
"env": {
"production:modern": {...},
"production:legacy": {...},
}
}

[ivancuric]

Maybe. I remember trying that approach, but I gave up on it. I had issues with manifest.json hashes and livereloading in a multi-output dev environment. Race issues probably.

[rosenfeld]

@thejameskyle if we run multiple build commands like in your example:

1 - Would it perform about the same due to the persistent caching? Or is it likely that it could be faster if both were built by the same process and reuse some steps?
2 - There's an html-webpack-plugin for Webpack that allows us to build htmls like @ivancuric suggested. @ivancuric told you that using script type=module is not recommended, which I agree, but he didn't explain the reason. One of the reasons is that some browsers, like IE11, will load both bundles even if they only execute one of them. The html-webpack-plugin allows us to provide a template and we can use logic in that template to decide how to build it while getting the generated names with hash included for permanent caching purpose, and we can then use some feature detection mechanism to decide which bundles to include in the page depending on the browser.

I see how Parcel could be a replacement for webpack for my own projects some day, but there are some features which I'm still missing in Parcel:

• source-maps: they are super important to me, specially as I get the stacktrace for every client-side error we detect, which makes it much easier to understand and fix the bugs. For debugging it is also very valuable even in development mode;

• the problem described in this issue, allowing me to provide separate modern and legacy bundles;

• I couldn't find any documentation on how permanent caching can be enabled in Parcel by appending chunk hashes to the generated assets, and how to clean-up older generated ones;

• I couldn't find how to separate some common bundles such as "vendors", "runtime" and "app" for example, so that the "vendors" would be often cached if they don't change very often.

The main issue I currently have with Webpack is the time it takes to build the assets in large projects, which is critical when I want to deploy a new release with a quick fix as soon as possible and it takes several seconds to build the bundles, delaying the deploy. But other than that, webpack works well for my needs. If it could implement persistent caching for building purposes it might get faster. I wish the best for Parcel and will keep an eye on it and if I can get the same features I currently need but a faster build time, I'd certainly consider moving to it.

Thanks for your efforts on improving the speed of assets bundle creations :)