Resources

Parcel

* --- WARNING!!! --- *
When you are on the docs pages for Parcel, make sure you are on the correct version (V1 vs V2)!

And make sure you have the version of Parcel you mean to have (parcel --version if you want to check).

Parcel Troubleshooting

• I'm not getting source maps!

  • Things to make sure:

    • Don't use --no-source-maps
    • Don't use --experimental-scope-hoisting

Webpack

Webpack Resources

Webpack Config File

If you want to use a config file with Webpack, you do so by making webpack.config.js in the root of your project, and having a single export:

module.exports = {
	// ...
};

For seeing all the options, and comments on what they do, reference the configuration page from the official docs.

You can use this interactive config builder tool, or this one, to help you get started.

Webpack Config File Intellisense / Autocomplete

If you are trying to get Intellisense to work in a webpack.config.js file, add a type annotation so VSCode can understand the config object:

/** @type {import('webpack').Configuration} */
module.exports = {
	mode: 'development',
	// ...
}

See my blog post on the topic, for details.

Webpack Troubleshooting

• Issues building to a subdirectory, with relative URLs (for example, lots of ChunkLoadError messages, bundles not loading)

  • You probably want to use the config.output.publicPath config option, and make sure that it ends with a slash (so, = '/app/, not = '/app)

Rollup

Rollup CLI

Although rollup supports a ton of arguments directly via CLI instead of through a config file, I generally would recommend sticking to a dedicated config file.

You can tell Rollup to explicitly read all values from the config file, and even switch between configs, by passing the config file name via -c or -config.

Example:

{
	"scripts": {
		"build": "rollup -c rollup.config.js",
		"build-debug": "rollup -c rollup-debug.config.js"
	}
}

Rollup Config File Intellisense / Autocomplete

If you are trying to get Intellisense to work in a rollup.config.js file, add a type annotation so VSCode can understand the config object:

/** @type {import('rollup').RollupOptions} */
const config = {
	//
};
export default config;

Or, for an array of configs:

/** @type {import('rollup').RollupOptions[]} */
const config = [
	// ...
];
export default config;

Rollup - Multi-Entry and Nested ESM Output

By default, Rollup bundles your code into single file exports, to reduce the number of chunks. E.g. output.umd.js and output.esm.js.

However, for multiple reasons, a package author dev might prefer to output in a way that more closely mirrors the input directory - with a 1:1 mapping that allows for users of the generated code to use nested imports (e.g. import {myFunc} from 'my-lib/nested/funcs').

To do this in Rollup, you need to use the output.preserveModules option, set to true.

There is also a semi-related issue with Rollup - unless explicitly passed via config.input, Rollup will optimize out nested index.js files. If you want those files / directories to be able to be drilled into from a consumer of your lib, you would need to explicitly mark them as entry point to Rollup. See Rollup Issue #3916 for details.

Reloading and Hot Module Replacement (HMR)

An important distinction to make; when considering the ability of a development environment to automatically refresh the browser / device when your local code changes, there are two popular mechanisms:

• Live Reloading:

  • This typically reloads the entire app, regardless of what has changed. In practice, this means that editing one component 30 layers deep in your UI will cause the entire page to reload, and your app state will be destroyed / reset

    • Some live-reloaders are at least able to avoid a full refresh if only CSS has changed, as that can easily be re-injected
  • This is sometimes referred to as Hot Reloading, if discussed within the same context as Hot Module Reloading (HMR), but this seems confusing to me

• Hot Module Replacement:

  • This only replaces the chunks of code that have actually changed, as opposed to the entire app. In practice, this often means that you can make changes to a component and only have that part of the app reload; everything else keeps it state.
  • This is far more complex than whole-page reloads, but also greatly speeds up the development process when it can be used.
  • HMR is only used for local development, and not actual production builds, so it often is implemented separately from the build task - e.g. rollup for builds, but snowpack for HMR and local dev.