Parcel Roadmap

[devongovett]

This is a public roadmap for Parcel. It is mainly a list of ideas that I have for the future of Parcel, and intended to give the community a sense of where we are going. In addition, if anyone is interested in any of these ideas and wants to help us get there, we welcome contributions! Feel free to discuss overall direction in the comments, but for specifics on any of these ideas, we should open a separate issue.

• Short term
  • Built-in Svelte support
  • Vue 2 support
  • UMD output format
  • ✅ Faster minification
  • ✅ Transpiling node_modules
  • ✅ Support the exports field in package.json
  • ✅ Faster bundling algorithm
  • Handle watching across symlink boundaries
  • ✅ Improved resolver for TypeScript
• Medium term
  • Project scaffolding tool
  • @parcel/register and @parcel/jest
  • Rework API for Bundler and Runtime plugins
  • Diagnostic auto-fixes
  • ⌛ LSP server
  • Improved Validator plugins
  • Cache garbage collection
  • Incremental bundling
  • Improved Node and Electron bundling support
  • Top-level await support
  • WASM support
• Long term
  • ⌛ Rewrite Parcel core in Rust
  • An SSR story
  • CI and remote caching

Short term

These are things we can do right away, in the next few months, or are already working on.

Built-in Svelte support

Integrate parcel-transformer-svelte into the default Parcel config, and document how to use Svelte with Parcel on the Parcel website.

Vue 2 support

We currently only support Vue 3, but Vue 2 is still much more widely used. We should support it. #6153

UMD output format

This was a feature that was dropped from Parcel v1, and it seems that many people use it. It exposes the output of a library as a global, or via AMD/CommonJS. #7312

✅ Faster minification

We already have a plugin for the new SWC minifier (@parcel/optimizer-swc). The goal will be for it to become the default. This involves testing, reporting, and fixing bugs in SWC itself.

We are also working on a new CSS compiler written in Rust, @parcel/css The first target for that will be to replace cssnano as our CSS minifier. We already have promising results. Eventually it will expand to handle other parts of Parcel's CSS pipeline, including CSS modules, dependency extraction, etc.

✅ Transpiling node_modules

We should support limited transpiling of node_modules. More and more modules are moving to shipping modern syntax to npm, which means apps using them that want to ship to older browsers need to compile them. Now that we are on SWC, the cost of doing this is more minimal, so we should enable this. Obviously, no non-standard (or pre-standard) syntax will be supported. No JSX, TypeScript, etc., only fully standard JS. #1655

✅ Support the exports field in package.json

Node added the exports field, which libraries are starting to use to provide different conditional entries to packages. We should support it as well. #4155

✅ Faster bundling algorithm

We are currently working on a new algorithm for the default Bundler plugin, which is responsible for grouping assets into bundles and performing code splitting. The current bundler is very slow and has some correctness issues as well. The new bundler addresses these issues. #6975

Handle watching across symlink boundaries

This has been a common complaint from people who use npm link and similar tools to symlink modules from different locations on their computer outside their project root. We should detect when this happens, and add additional watch roots. #4332

✅ Improved resolver for TypeScript

We should support baseUrl, paths, etc. See #4936.

Medium term

These are ideas that are further out and require a bit more thinking, but not too giant.

Project scaffolding tool

Although it’s already pretty easy to start a new project with Parcel, we could make it even easier by introducing a project scaffolding tool. It would be similar to create-react-app and others, but framework agnostic, with various templates for different types of apps and libraries. You'd run yarn create parcel or npm init parcel, which would ask you a series of questions, for example:

• What kind of project are you building? (e.g. app, library, web extension, parcel plugin, etc.)
• What framework would you like? (e.g. React, Vue, Svelte, Vanilla, etc.)
• What language are you using? (e.g. JavaScript, TypeScript, CoffeeScript, etc.)
• What styling method would you like? (e.g. plain CSS, CSS module, SASS, Tailwind, Styled Components, Emotion, etc.)
• etc.

In addition to creating new projects, I think this could also be useful for adding new technologies to existing projects. For example, maybe you have a project and decide you want to add Tailwind CSS to it. Normally you need to install a bunch of dependencies, create some config files, etc. We could automate this under a single command, e.g. parcel add tailwind.

@parcel/register and @parcel/jest

Right now, Parcel discourages you from using Babel when it’s possible to use the built-in SWC-based transpiler. This improves performance of Parcel builds, but it may not be entirely possible to remove Babel from your project due to other tools you use, such as testing frameworks. We should expose Parcel’s transformers so it is possible to do single-file builds that integrate with other tools.

• Parcel core should have a transform method that can transform individual files rather than bundling the entire app. Useful for the below packages, but also any other transformation you might want to do for custom purposes.
• @parcel/register should be a Node require hook that transforms JS as it is being loaded in Node. This can be used with tools like Mocha, as well as e.g. Node servers to transpile JS/TS.
• @parcel/jest - a Jest transformer using Parcel rather than Babel.

See #2396

Rework API for Bundler and Runtime plugins

The Bundler and Runtime plugin APIs are currently marked as experimental, and are in need of a rework to make them easier to use. In particular, Runtimes are probably not the right abstraction, and the Bundler API is too hard to use for most use-cases because you’d have to rewrite the default bundler just to get the basics. This requires some more thought.

Diagnostic auto-fixes

Parcel has rich diagnostics with detailed information about where a problem occurred, along with hints about potential fixes. We should make these hints more structured, which will open up the possibility of having auto-fixes. The idea would be that you’d press a key in your terminal (or via an editor integration) when a diagnostic is showing to accept a potential fix to a problem. This could for example change your code in some way, install an npm package, etc.

⌛ LSP server

The above leads into the potential of a Parcel LSP server, or editor integration. This would allow Parcel diagnostics to be shown right in your editor, auto fixes to be accepted, etc. While things like TypeScript already have many diagnostics that we wouldn’t need to duplicate, Parcel does have additional diagnostics for many build-related problems. It also supports cross-language integration. We could for example support Jump To Definition for CSS modules. We’ve already done some prototyping in this area with promising results.

Improved Validator plugins

This leads to improving the Validator plugin support in Parcel. Many people desire to only run one build tool, and fail the build on things like TS type errors. We currently have Validator plugins, but they are experimental and somewhat buggy at the moment. We should improve validators to have better support for TypeScript/ESLint/etc.

In addition to many people's desire to only run one build tool, another benefit of integration with Parcel is caching. For example, we could have a parcel validate command which only runs Validators on files that changed. This could make e.g. ESLint much faster to run on large repos.

Longer term, we could also do interesting things with language embedding, for example, type checking of TypeScript inside MDX, or Svelte/Vue SFCs. This could make it much easier to add TS support for new languages as well.

Cache garbage collection

Right now, Parcel’s cache grows unbounded as you change files, and eventually may take up a significant amount of disk space. We should address this by implementing garbage collection, which will periodically clean up old cache entries.

Incremental bundling

In addition to the faster bundling algorithm discussed above, we have also started investigating incremental bundling. Rather than running the entire bundling algorithm on the whole graph for every change, we could ideally update an existing bundle graph incrementally given a previous graph and a set of changes. In many cases, this is very simple because most changes don’t introduce dependencies at all. And in other cases, we know based on the dependencies that were added that no new bundles will be created. This could speed up both development and production builds significantly for large apps, but will need to be done very carefully so we ensure the same result is always reached if done incrementally or on the whole graph. #6047

Improved Node and Electron bundling support

Parcel’s support for bundling to Node targets is pretty basic, and could be improved a lot. For example, we don’t support native node modules, don’t copy files referenced by fs.readFile into the dist dir, etc. See #2493.

In addition, our Electron support could also be improved. See #2492.

Top-level await support

This is challenging to implement correctly, but we should support it as it is part of the JS language standard. #4028

WASM support

We had it in Parcel 1, but it didn’t make it for Parcel 2. We should implement the Web Assembly Modules spec. #1325

Long term

These are large projects that may take a while to implement, and haven’t been fleshed out much yet.

⌛ Rewrite Parcel core in Rust

We have already started using Rust quite heavily in Parcel, with our new JS and CSS compilers, image optimizer, etc. The next step will be to replace more parts of Parcel with Rust counterparts. The biggest part to replace is Parcel core itself, starting with our data structures like the asset and bundle graphs, the request system, and the individual data structures that make up all of these. We already have public wrapper objects for all of them, so it should be fairly easy to replace the internals without breaking the API.

The eventual goal would be to also support Rust-based plugins, but this is harder, and I think JS plugins do provide value for easy integration with almost everything. I think we can get some significant performance improvements by using Rust for the core data structures, with JS accessors, because we won’t need to pay any serialization cost to send them between threads.

Perhaps we can also explore inverting our current model, where JS owns the worker farm and calls plugins, to a model where Rust owns the concurrency model and calls to JS plugins where needed. This will require further exploration.

An SSR story

While Parcel won't become a framework, we should have some story around SSR/SSG. It should ideally be framework agnostic, and perhaps lower level so that plugins can be written on top of it. Especially with React Server Components coming, it seems the industry is moving toward more SSR and not less, so it will be important for Parcel to support something in this space. I don't exactly know what yet.

CI and remote caching

Parcel’s current caching is very focused on development. We should expand this to be more useful in CI. This will require some thought about how we detect changes efficiently with version control, how we handle dev dependencies (e.g. node_modules), etc.

In addition, we should investigate remote caching. This would allow a team of developers to share a common cache between their machines, so that if one dev has already built a file it doesn’t need to also be built by other devs. Other build systems for other languages like Bazel/Buck do this, and it could potentially speed up builds for both development and CI.