Multi-compiler mode — output multiple bundles about parcel HOT 8 CLOSED

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 ...

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

from parcel.

I see. Safari has the same problem and the workaround basically just ensures that the code doesn't get run twice.
I have no problem making my sites heavier and slower for old browsers if I can make them lighter and faster for modern browsers.

from parcel.

There are other reasons to support multiple targets. Not all every modern browsers (those supporting type=module) support all sort of features. It's a good thing to provide multiple target so that more modern browsers could download a lighter bundle.

from parcel.

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.

from parcel.

@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 :)

from parcel.

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

The linked article wholeheartedly recommends using <script type="module"> for feature detection with the addition of a small workaround for Safari 10 which will load and run both <script type="module"> and <script nomodule>. This has been fixed in Safari 11, but Safari 10 isn't quite dead yet.

from parcel.

If you do that IE11 will take longer to load the initial page, because it has to download both versions even though just one of them will be executed.

from parcel.

Going to close this since it is solved in Parcel 2. You can set up multiple targets like this in your package.json, and they will be compiled in parallel:

{
  "browser": "dist/legacy/index.js",
  "browserModern": "dist/modern/index.js",
  "targets": {
    "browserModern": {
      "engines": {
        "browsers": [
          "last 1 Chrome version"
        ]
      }
    },
    "browser": {
      "engines": {
        "browsers": [
          "> 0.25%"
        ]
      }
    }
  }
}

from parcel.