parcel: Slow hot reload builds in Parcel v2
🐛 bug report
Hi all! Loving Parcel. Very excited about Parcel 2.
My Parcel 1 app is hot-reloading very slowly in Parcel 2. The reason I’m upgrading is that Parcel 1 sits at about 100-110% CPU usage even when not compiling my app. Parcel 2 doesn’t do this at all (yay) but compilation time for hot module reloads has gone from 200ms to 4.0s (oh no).
We have a fairly big application, lots of files and modules, but nothing that I would consider unreasonably big. Around 777 JS files in our src directory.
I don’t actually know how to debug this compilation speed problem. I’m not sure whether this is something with our Babel setup, whether I need to update a module, or whether my targets are set up incorrectly (I’m using the default >0.25%).
(P.S. I’ve tested the Parcel 1 100% CPU problem with a dummy app containing 1,000 files - and as I add more and more files to the app, the CPU usage goes up. At 1,000 files it’s somewhere between 50-60%.)
🎛 Configuration (.babelrc, package.json, cli command)
This is my .parcelrc:
{
"extends": "@parcel/config-default",
"transformers": {
"*.svg": ["@parcel/transformer-svg-react", "@parcel/transformer-js"],
"*.png": ["@parcel/transformer-raw"],
"*.jpg": ["@parcel/transformer-raw"],
"*.graphql": ["parcel-transformer-graphql-ast"],
}
}
This is my babel.config.js:
module.exports = function(api) {
api.cache(true);
const presets = ['@babel/preset-react'];
if (process.env['NODE_ENV'] === 'test') {
presets.push([
'@babel/preset-env',
{ modules: 'commonjs', targets: { node: 'current' } },
]);
}
const plugins = [
[
'auto-import',
{
declarations: [
{
default: 'React',
path: 'react',
members: ['useState', 'useEffect', 'useContext', 'useRef'],
},
{ default: 'PropTypes', path: 'prop-types' },
{ default: 'classnames', path: 'classnames' },
{
default: 'withStyles',
path: '@material-ui/core/styles/withStyles',
},
],
},
],
[
'babel-plugin-root-import',
{
paths: [
{ rootPathPrefix: '~', rootPathSuffix: 'src' },
{ rootPathPrefix: '#', rootPathSuffix: 'test' },
],
},
],
[
'transform-inline-environment-variables',
{
include: [
'CONTACT_SALES_FORM_ID',
'CONTACT_SUCCESS_FORM_ID',
'SENTRY_FRONTEND_DSN',
],
},
],
'@babel/plugin-syntax-import-meta',
'@babel/plugin-proposal-class-properties',
'@babel/plugin-proposal-function-sent',
'@babel/plugin-proposal-export-namespace-from',
'@babel/plugin-proposal-numeric-separator',
'@babel/plugin-proposal-optional-chaining',
'@babel/plugin-proposal-throw-expressions',
];
return {
presets,
plugins,
};
};
If anybody has any suggestions on where I should be looking, I’d love to get to the bottom of this, in case anybody else sees the same thing.
🤔 Expected Behavior
It should be wicked fast! Parcel 1 was very fast, although it did seem to hog a single CPU core at 100% for our application.
😯 Current Behavior
Hot module reloading builds in Parcel 1 took ~200ms, and the same type of builds in Parcel 2 take anywhere between 2-4 seconds.
A hot reload looks like:
yarn run v1.22.4
$ NODE_ENV=development parcel index.html --no-autoinstall --public-url /dist
ℹ️ Server running at http://localhost:1234
✨ Built in 4.32s
Parcel 1:

Parcel 2:

🌍 Your Environment
| Software | Version(s) |
|---|---|
| Parcel | 2.0.0-beta.1 |
| Node | v13.14.0 |
| npm/Yarn | yarn 1.22.4 |
| Operating System | macOS |
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Reactions: 9
- Comments: 18 (10 by maintainers)
Should be a lot faster in v2.8. https://parceljs.org/blog/v2-8-0/
@dsgkirkby This applies to you as well: https://github.com/parcel-bundler/parcel/issues/4143#issuecomment-997528950
“bundling” takes the most time in your case.
If you want to try the new bundler right now, do this: https://github.com/parcel-bundler/parcel/issues/5772#issuecomment-1133377231 (you don’t have to necessarily use the nightly version)
Using
parcel index.html --profile.I also ran into this when trying to convert an app to parcel - in our case, it typically takes about 10s for parcel to rebuild after changing just a single file. In the case of the trace below it actually took 15s (maybe unlucky, maybe overhead?)
Here’s the trace: profile-20220731-134852.trace.zip