Snowpack: Idea for faster Parcel production builds

[devongovett]

Parcel is probably doing a bunch more work than it needs to in your case. Since you are handling running babel/ts etc. prior to running Parcel, you could disable Parcel's built-in babel support. That should improve build times for production considerably.

To do that, you can add something like "browserslist": ["last 1 Chrome version"] to the package.json that Parcel reads. This will let Parcel see that it doesn't need to run babel-preset-env to compile the code further. I see that you're already copying the package.json into the build directory, so this should be easy for you to add.

[FredKSchott]

Oh nice! Yes definitely interested in this, I'd tried moving the cache location somewhere that could be shared across builds but it didn't seem to speed up the basic CSA app templates. Does that sound right or did I do something dumb?

We currently recommend doing your Babel preset-env transpiling during build and not dev, so I think Parcel is the right step for Babel preset-env in our workflow. Since we ask you to use a modern browser during development anyway, this hasn't been an issue yet but we could potentially revisit.

Also while I have you here, when would you recommend we move to Parcel 2 alpha/beta? We're not using any plugins, so we'd only be looking for stability in the core behavior. I'd considered using "@next" but it seems to be a few months old at this point and pinning to nightly seems too risky.

thanks again for all of your work on Parcel! Snowpack truly wouldn't be possible without it

[devongovett]

Ah ok, I was under the impression that you were running babel outside Parcel and weren't relying on it, but I guess that was incorrect. Makes sense that you aren't running preset-env in dev. 😄

By default, the cache dir is in the current working directory where parcel is run from. But you can override this with the --cache-dir CLI option or cacheDir API option.

For Parcel 2: we are going to have another alpha release very shortly (next couple days) so I'd wait for that. It's pretty stable if you aren't using any plugins I'd say. Some iteration is still going on with the plugin APIs. There'd be three major benefits to upgrading I'd say:

• Tree shaking is on by default in v2, and is a lot more stable (tons of bugs fixed). This should help reduce production build size considerably. It's been tested on some pretty big apps, so should work fairly well at this point.
• Code splitting is much improved. We automatically move modules that are shared between multiple bundles out into their own bundles so they can be cached independently. We've seen huge entry bundle size reductions because of this, and much better cacheability when navigating between pages.
• Native ESM output is supported, along with automatic differential loading. If you use <script type="module"> to load your app, Parcel will also generate native ESM output. You can also add a nomodule version pointing at the same source file and Parcel will compile a version for old browsers as well.

Let me know if you have more questions! 😄

[FredKSchott]

100% please let me know about the next Parcel alpha release. I think it makes sense for us to upgrade given where we are in this project, and I'd love to get you some alpha feedback if it helps.

Re: --cache-dir that was what I'd tried, but for whatever reason it didn't seem to improve speed. My best guess was that because I was running it on one of the starter templates there wasn't enough to cache.

[pika-ci[bot]]

:truck: This issue has been moved!
Continue the discussion on our project message board:
https://www.pika.dev/npm/snowpack/discuss/169 • What is this?