RFC: New Bundler in Gatsby

[imjoshin]

TLDR: We're looking at changing the underlying bundler at Gatsby. See the "How can I help?" section to see what we're looking to get from you, our community!

Motivation

We at Gatsby are always aiming to provide the most efficient product to create blazing fast websites. A significant portion of Gatsby’s build is taken by bundling generated assets for deployment. Currently, we use webpack to handle that bundling. Though webpack has been a tried and true tool for web applications in the last decade, it has recently proven to be slow, relatively speaking. Other bundlers (specifically bundlers using highly performant languages like Rust/Go) have become mainstage that provide improvements in speed and bundler size.

We’ve done some initial benchmarking with a simple test site, which can be found here. In switching bundlers, we plan to see improvements in warm, cold, and develop builds.

While we aim to continuously improve the build speed and efficiency, we want to enable the use of modern tools without reducing the feature set. As we iterate on this project, we hope to provide updated APIs that will make swapping tools much easier in the future. We plan to provide support for the best development tools and increased speed as you develop your blazing fast websites.

Considerations

• Migration Plan
  • There will be action steps for current Gatsby websites that modify bundler configuration to move from one bundler to another. While we hope to make this manual process minimal, we do anticipate significant changes for more advanced configurations.
• Configuration API
  • We hope to take this opportunity to simplify the API for bundler configuration.
• Bundler plugin support
  • As webpack covers a large majority of the “bundler market”, there are numerous plugins for most use cases.

Alternatives

• webpack tweaking
  • Over time, numerous improvements have been made to the way Gatsby’s webpack configuration currently works. Though there could be potential for further improvements, moving to a new bundler will likely see larger improvements.

What’s next?

Over the next few months, we’ll be working on a proof of concept for moving bundlers. As we continue discussing this RFC, we’ll be iterating on the project. Expect another RFC in a few months as these changes continue to be hashed out.

With the launch of Gatsby 5, we’re planning to ship a new bundler by default with an opt-out flag to stay on the current webpack configuration.

Adoption Strategy

As of now, Gatsby’s plan is to support both the new configuration and an opt-out flag to continue using webpack throughout the lifetime of Gatsby 5. We will be creating a new API for a generic onCreateBundlerConfiguration (see: webpack configuration) and will have a migration guide when this change launches.

How can I help?

At this stage of the RFC, we’re principally looking for areas we’ve missed while we’re evaluating and planning for a bundler change. There will be a later stage where we have actual projects for you to try and provide more detailed feedback, and we will provide updates in this discussion.

Our questions to you, our users are:

1. What are key consideration we’re missing and why is that important to you?
2. Within the considerations we currently have listed, what are edge cases we should be sure to take note of?
3. What should Gatsby be aware of when switching bundlers in reference to your areas of expertise (plugins, performance, etc)?

While I’m sure some of us have strong preferences for specific bundlers, we’re really focused on understanding the considerations regardless the specific target bundler so that we responsibly frame and plan for this kind of change.

Resources

• https://bundlers.tooling.report/
• https://github.com/j0sh77/bundler-benchmarking/blob/main/results/with-styles.md
• https://www.gatsbyjs.com/docs/how-to/custom-configuration/add-custom-webpack-config/

[endymion1818]

Speaking purely from a selfish standpoint, Vite seems to be clearly the winner in terms of parse time and bundle size. Yes I'm one of those people who cares about every byte that gets sent to the client. I appreciate though that there are many other considerations especially for plug-in maintainers and the overall health of the Gatsby ecosystem.

[herecydev]

Did you see this: https://github.com/j0sh77/bundler-benchmarking/blob/main/results/with-styles.md? esbuild is objectively faster and smaller...

[tujoworker]

Vite uses rollup.js and Babel for builds. But during dev mode, they use your browser the "bundle" which makes it so fast. While all dependencies are bundled using esbuild. So its good mix of bundler's.

[phil-lgr]

I don't find the numbers nor the rationale convincing. Webpack has a massive ecosystem, massive downloads per month (still growing, see https://www.npmtrends.com/vite-vs-webpack), is still improving fast and has support ($) from major tech companies.

Just earlier, the folks at Vercel have proven once again that you can make webpack blazing fast if you focus on improving existing projects and not reinvent the wheel: https://nextjs.org/blog/next-12-1

Taking your rough benchmarks, you are telling us that you are ready to break most Gatsby plugins (a big portion of Gatsby plugins are just wrapper for webpack plugins and loaders) and alienate Gatsby developers for ~4 seconds in build time? The NextJS team has proven that it is possible to get very fast build times by replacing specific parts that are slow, with faster alternatives, why can't Gatsby do the same?

I don't find the arguments strong enough for such a major change. I feel that there are A LOT of low-hanging fruits from the likes of esloader, swc and other babel/tsc/terser replacements that could be tried before Gatsby introduce such a massive change.

Although this is an RFC, it looks like the decision has been taken already... v4 already included Vite as a dependency to support TS in config files.

[phil-lgr]

If this goes through, I'll be one to leave for nextjs... after actively getting client onboard with Gatsby for the last 2 years.

I can't commit to Gatsby v4 knowing that all my custom Gatsby plugins will break in the future, I also see 0 incentive in relearning the same concepts (plugins, loaders etc) in the vite ecosystem, especially when I see that nextjs has no problem being fast with webpack and innovating while not breaking the entire build ecosystem

[imjoshin]

Hi @phil-lgr ! Thanks for your thoughts and the additional considerations here.

While we haven't started iterating on our proof of concept, we are planning on switching bundlers. We value the feedback of our community (like yourself) and that will help influence the direction of the PoC and how we develop these APIs.

One thing to note is that we're planning on having an "opt-out" flag to fallback to webpack, which should give plugin maintainers ample time to update any changed APIs. That said, Gatsby users will be able to wait until they're ready to switch to the new bundler. Your concern is valid, and we're planning on making that process as seamless as possible.

[ScriptedAlchemy]

A decent amount of webpack “slowness” is related to it being node based, the buffers used to read the FS are extremely slow for UTF strings.

I’ve been working on this for a little while.
My average prod compile takes 1.5 seconds with webpack. Next version of node should fix the bottlenecks 😊

if you need a speed boost. Tweak libuv thread pool size

[dopry]

@ScriptedAlchemy, Can you link some references?

[KyleAMathews]

very cool! Would love to read more about this as well.

[tujoworker]

Zack, that sounds amazing! Is it this what you talk about? https://hackernoon.com/how-libuv-thread-pool-can-boost-your-node-js-performance-bel3tyf

[tujoworker]

Tweaking the "libuv thread pool size" made no measurable difference on my setup 🤔

[ashhitch]

Everyone always talks about build speed but another important factor is memory usage during the build.
E.g if more builds could be under 1GB Free plan level in Gatsby Cloud it could help with adoption (and I suspect by proxy support requests!)
Would be interesting to see the benchmarks for this across parcel, vite etc

[imjoshin]

Hey @ashhitch ! Definitely. That's one of our key metrics we're hoping to get as we continue our research/iteration. We'll be sharing updates as we have more metrics. 😄

[feedm3]

Isn't the bundler just important for the Building production JavaScript and CSS bundles part of the build process? How would a different bundler have an effect on query running or creating the HTML pages?

Let's say you have a large page, the most time-consuming part here is building the HTML files and not producing the Javascript bundle. This is also the most memory and CPU consuming part. For example we have an 80k pages project, bundling the Javascript takes around 1 minute, creating the pages is 90 minutes.

So for running a build, the impact of a new bundler is quite limited, right? I can imagine that it gets more interesting when running Gatsby in dev mode because creating HTML pages isn't done there and the bundling is actually one of the slowest parts.

[herecydev]

It probably wouldn't be and that should be optimized, but that doesn't detract from changing the bundler. It's highly dependent on the scale of the sites; our page count is really variable depending on the number of products we're building for. When that number is very low <100 we're seeing the webpack stuff take ~50s and page creation ~ 3s in a process that takes ~90s so obviously vastly impacted by the bundling.

[imjoshin]

Hey @feedm3 and @herecydev, thanks for your input!

I can imagine that it gets more interesting when running Gatsby in dev mode because creating HTML pages isn't done there and the bundling is actually one of the slowest parts.

As Gatsby continues to grow and reach a broader audience of developers, we're hoping to make the experience using Gatsby in the CLI more user-friendly. While we don't have any hard metrics in the https://github.com/j0sh77/bundler-benchmarking repo yet, we do anticipate a more substantial effect on the gatsby develop spin up time, for both small and large sites. 😄

[wardpeet]

A bundler gives you more than just compiled code. You get a dependency tree, places you can hook into, ... This will help us in the future to minimize work on rebuilds and know when to clear the cache and which parts of the cache.

[mattbeck]

The way gatsby ships webpack is already a headache, the more I think about this, the more I struggle to imagine a scenario where this is going to make life better.

The rollout of major version changes has hardly been smooth even without introducing breaking changes on this scale.

Drop the opt-out, default to webpack and let people who want something different play with your new toy and maybe, maybe it'd start to make more sense, but this just seems like a horrible idea for the ecosystem at this point in time.

[imjoshin]

The rollout of major version changes has hardly been smooth even without introducing breaking changes on this scale.

Hey @mattbeck , I appreciate your feedback, and it's definitely something that's going to be top of mind. We don't want to make changes like this without careful consideration. 😄

Assuming a breaking change to the Gatsby API, what would the ideal upgrade process look like to you for something like this?

[mattbeck]

Soft deprecation warnings about webpack in the next major version, suggest people opt-IN to the new thing, and let them know that it will default to the new bundler starting with the following major version.

[el7cosmos]

@mattbeck major version in semver means breaking/incompatible changes. Deprecation and opt-IN, which is backward compatible should be introduced in the minor version

[mattbeck]

As a concept yes I absolutely agree. Practically I'm going to have to disagree on this one. Gatsby's release cycle is pretty rapid. Upgrades from v2 to v3 were a nightmare for more complex sites, v4 was a little smoother but followed up just as a lot of folks were getting to v3. Unless they are going to slow their pace of major releases they need to take a more measured approach.

[njbmartin]

There are a few things to bear in mind with those benchmarks, and there are a few takeaways...

For the majority of people, there will only be a small gain (eg. ~4 seconds). However, for much more complex sites, which Gatsby is trying hard to cater to as well (eg. enterprise), there is a massive improvement:

Note: this is essentially the same as our use-case, so we'd benefit from this.

For even more complex sites, webpack doesn't even work:

So this is likely to be a key motivator for moving away from webpack to something like esbuild.

On the flip-side, I agree with the concerns about existing plugins that currently rely on webpack. Gatsby has a huge eco-system of plugins that haven't been updated to support Gatsby v4, but they still work. Changing the bundler is likely to kill off a number of those. Also, webpack has a pretty great API and is highly customisable with plenty of plugins too.

Some of the other bundlers, despite being blazingly fast, are still relatively new, and inherently risky if you're going with an opt-out approach.

I thought this feature comparison was quite interesting as it mentions esbuild and vite:
https://css-tricks.com/comparing-the-new-generation-of-build-tools/#feature-comparison

It seems esbuild is still not yet production ready and relying heavily on the community to create plugins for things like HMR.

One worrying factor of esbuild is that there is a whole section dedicated to it being flagged by anti-virus software due to it being native code.

[herecydev]

The eco system point is fair but we need to be careful in drawing comparisons, as far as I'm aware the following would be impacted onCreateBabelConfig and onCreateWebpackConfig as they are both specific frameworks that are currently used that will potentially no longer be relevant. As far as I'm aware, these have always been leaning towards escape hatches rather than something every plugin should use.

So the question should be, how often do non-official gatsby plugins or local plugins use either one of those? Looking at our plugin list I can only see one that sticks out: gatsby-plugin-webpack-bundle-analyser-v2 which would have to be converted somehow.

Would be good to actually provide some metrics that I'm sure Gatsby have.

[patspam]

Love this initiative. Big vote of support here.

One data point in support of esbuild is that another awesome dev toolchain, Serverless Stack uses it for building/bundling lambdas. They chose it to make their live lambda debugging developer experience as fast/awesome as possible.

[edardev]

Yes! Faster and smaller, please 👏👏

[kaushalyap]

@j0sh77 Which bundler do you folks going to move to ? ESBuild or Vite?

[imjoshin]

Hey @kaushalyap ! We've been working through some proof of concept ideas and will be sharing an update here once we know the direction we're going to go in. We're hoping to focus this discussion on edge cases and considerations that should be a factor in that decision. 😄

[edardev]

When will this be implemented? Should we wait until is released and tested?

[imjoshin]

Hey @edardev ! We're hoping to have a canary of a proof of concept shortly. You'll be welcome to test that, but it won't be production ready. The full release is not planned for a few more months (also pending our decision here).

[edardev]

That's awesome, thank you for the information 👏

[tujoworker]

I personally would love to see the Vite approach, where Vite uses the browser during development for handling project files, while it uses a faster bundler (esbuild) for dependencies, but still uses a well supported/large ecosystem bundler for the prod builds (Rollup/Babel support).

So yeah, a Vite approach, but with Webpack, would be gold ✨

And if there are special Babel Plugins, they still can be potentially run in the "browser" during development (or on the dev server if needed).

I have some experience with esbuild, and when you try to use it with emotion it gets tricky – esbuild still does not support the React v17 jsx transform.

Also interesting to see is, that many (most) of the esbuild community plugins do use Babel (and not Go) to make the work. So this slows down things significant again, because, suddenly, your code needs to build an AST anyway. And what about the memory consumption then? 🤦‍♂️

Another thing I want to share is the removal of GraphQL queries. Right now this plugin does the job. But it could be written like the flow team did for removing flow types – the performance looks like a lot faster, even its written in Node.js.

swc on the other hand, tries hard to create a better system/interface so quality plugins can come into the game. But its very early still and experimental.

Very interesting is also bun but it may take some years to catch up.

In conclusion:

• The build time is less important from what I have experienced, while the ecosystem is very important.
• Faster development startup/refresh time would be very appreciated.

[imjoshin]

Hey @tujoworker ! Thanks for the input. I agree with the sentiment that we want Gatsby's development time to speed up, and that's one of our main focuses going forward. 😄 We'll take a look into the references you've passed along!

[imjoshin]

Hey all!

Through the month of April, the Gatsby Core team pursued a proof of concept for migrating to a faster bundler with Parcel to produce the fastest developer experience for Gatsby developers. Goals of the proof of concept can be found below in the original RFC description.
Our proof of concept used Parcel as the target bundler, since Parcel:

1. is already used within the TypeScript specific portion of the Gatsby build process,
2. scored favorably on our initial benchmarks
3. appeared to be the most feature complete among the candidate bundlers when we began the proof of concept process

The outcome of the proof of concept is that Gatsby will not migrate to a new bundler as part of Gatsby 5. There are few key reasons why we made this call:

1. There are some key features Gatsby requires, some of which are on Parcel’s roadmap, but are not yet implemented (within Parcel core or community plugins). For example, there is currently no support for .node files in package dependencies, like lmdb and sharp
2. We wish to de-risk
   1. the remaining high-impact features we have planned for Gatsby 5
   2. impact to the many Gatsby plugin authors that leverage webpack API’s today

To be clear, we’re not saying “never” to a new bundler in Gatsby. For example, Gatsby already uses and will continue to use Parcel for our support of gatsby-node.ts and gatsby-config.ts.

We are, however, saying “not right now.” Further, the Parcel core team has been fantastic to work with, and we plan to stay in touch as Parcel evolves, and will re-evaluate when the necessary features are planned for development with their team.

So, where do we go from here?

We believe there are meaningful optimization opportunities within the Gatsby build process, and we’re building a plan for those optimizations which we’ll release as they’re implemented.

Thank you to everyone who contributed their perspectives on this research.

[kaushalyap]

Any way to improve dev server response times?

[oorestisime]

Came here to say its quite unfortunate to see this is not getting on the immediate roadmap!

Since moving to v4 and webpack 5 the development building has been super slow and to a point that we need to spend time thinking and experimenting on how to solve this instead of shipping meaningful features. And building less pages is not a solution at this point.

It takes us a whopping 300 seconds to build development bundle and by reducing drastically the nodes we build we arrive at 180 seconds which is still super slow compared to what the experience was a little bit back! (Working on a decent Macbookpro from with 16gb Ram and 2.9 i5 intel). 120k lines of code between js and css files and around 1000 files.

For comparison our production builds which build even more nodes take only 95 seconds to build bundles (CircleCi Docker / X-Large)!!!!!!!

[oorestisime]

Small update: fixed an autoprefixer issue on our codebase and a conflicting url (template vs page) and saw significant improvements. Right now at around 40-60 seconds.I still think that this is a ton of seconds more than it should but its bearable i guess.

[shalawfatah]

Bun Bun Bun Bun Time🥇 👍 💯

[CSharperMantle]

bun is now experimental, however. Maybe we wait till it goes to v1.0?

[ScriptedAlchemy]

Don't jump on hype train. Give it several months and ensure it's actually going to exist and be viable.

Leaving webpack, for project with a userbase this large - bet on safe technology thats established. Innovation is good - but gatsby has a obligation to its users to pick tried and true replacement of webpack.

I would still suggest offering support for webpack. Like angular supports webpack and esbuild. If it's possible to do so.

Also webpack 6 should have vast improvements + the main problem (fs.readFile buffers utf8 which makes IO very slow) so webpack gets a bad rap because of faults in part caused by node.

We are working to resolve that in node 19

[sandren]

I think this is what you've been waiting for: https://turbo.build/pack 👈

[tujoworker]

@j0sh77 Soon a brand new port of Webpack, written in Rust will be released. They need to know what Hooks they also should port.

Please help them out with everything we need to make it work with Gatsby 🙏🏻

https://twitter.com/scriptedalchemy/status/1620622790138400769?s=46&t=EGW3V18F3st94N9vwLXrXw

[PaulieScanlon]

Hi team i tried gatsby@alpha-rspack

Got the following error, but am super keen to keep slugging away on this if its helpful?

Module parse failed: Unexpected token (60:7)
File was processed with these loaders:
 * ./node_modules/gatsby/dist/utils/babel-loader.js
You may need an additional loader to handle the result of these loaders.
|   const {
|     0: label,
>     1: ...rest
|   } = useMemo(() => getTextFromChildren(children), [children]);
|   const args = React.useMemo(() => [label, opts], [label, opts]);

  ModuleParseError: Module parse failed: Unexpected token (60:7)
  File was processed with these loaders:
   * ./node_modules/gatsby/dist/utils/babel-loader.js
  You may need an additional loader to handle the result of these loaders.
  |   const {
  |     0: label,
  >     1: ...rest
  |   } = useMemo(() => getTextFromChildren(children), [children]);
  |   const args = React.useMemo(() => [label, opts], [label, opts]);

Gatsby Info

  System:
    OS: macOS 13.2
    CPU: (10) arm64 Apple M1 Pro
    Shell: 5.8.1 - /bin/zsh
  Binaries:
    Node: 18.0.0 - ~/.nvm/versions/node/v18.0.0/bin/node
    Yarn: 1.22.19 - /usr/local/bin/yarn
    npm: 8.6.0 - ~/.nvm/versions/node/v18.0.0/bin/npm
  Browsers:
    Chrome: 111.0.5563.64
    Firefox: 110.0
    Safari: 16.3
  npmPackages:
    gatsby: ^5.8.0-alpha-rspack.4 => 5.8.0-alpha-rspack.4+1d1231e9a7
    gatsby-plugin-gatsby-cloud: ^5.0.0 => 5.0.0
    gatsby-plugin-google-analytics: ^5.0.0 => 5.0.0
    gatsby-plugin-image: ^3.0.0 => 3.0.0
    gatsby-plugin-mdx: ^3.20.0 => 3.20.0
    gatsby-plugin-mdx-embed: ^1.0.0 => 1.0.0
    gatsby-plugin-postcss: ^6.0.0 => 6.0.0
    gatsby-plugin-sharp: ^5.0.0 => 5.0.0
    gatsby-plugin-sitemap: ^6.0.0 => 6.0.0
    gatsby-source-filesystem: ^5.0.0 => 5.0.0
    gatsby-transformer-json: ^5.0.0 => 5.0.0
    gatsby-transformer-sharp: ^5.0.0 => 5.0.0
  npmGlobalPackages:
    gatsby-cli: 5.7.0

[so1ve]

Hi team i tried gatsby@alpha-rspack

Got the following error, but am super keen to keep slugging away on this if its helpful?

Module parse failed: Unexpected token (60:7)
File was processed with these loaders:
 * ./node_modules/gatsby/dist/utils/babel-loader.js
You may need an additional loader to handle the result of these loaders.
|   const {
|     0: label,
>     1: ...rest
|   } = useMemo(() => getTextFromChildren(children), [children]);
|   const args = React.useMemo(() => [label, opts], [label, opts]);

  ModuleParseError: Module parse failed: Unexpected token (60:7)
  File was processed with these loaders:
   * ./node_modules/gatsby/dist/utils/babel-loader.js
  You may need an additional loader to handle the result of these loaders.
  |   const {
  |     0: label,
  >     1: ...rest
  |   } = useMemo(() => getTextFromChildren(children), [children]);
  |   const args = React.useMemo(() => [label, opts], [label, opts]);

Gatsby Info

  System:
    OS: macOS 13.2
    CPU: (10) arm64 Apple M1 Pro
    Shell: 5.8.1 - /bin/zsh
  Binaries:
    Node: 18.0.0 - ~/.nvm/versions/node/v18.0.0/bin/node
    Yarn: 1.22.19 - /usr/local/bin/yarn
    npm: 8.6.0 - ~/.nvm/versions/node/v18.0.0/bin/npm
  Browsers:
    Chrome: 111.0.5563.64
    Firefox: 110.0
    Safari: 16.3
  npmPackages:
    gatsby: ^5.8.0-alpha-rspack.4 => 5.8.0-alpha-rspack.4+1d1231e9a7
    gatsby-plugin-gatsby-cloud: ^5.0.0 => 5.0.0
    gatsby-plugin-google-analytics: ^5.0.0 => 5.0.0
    gatsby-plugin-image: ^3.0.0 => 3.0.0
    gatsby-plugin-mdx: ^3.20.0 => 3.20.0
    gatsby-plugin-mdx-embed: ^1.0.0 => 1.0.0
    gatsby-plugin-postcss: ^6.0.0 => 6.0.0
    gatsby-plugin-sharp: ^5.0.0 => 5.0.0
    gatsby-plugin-sitemap: ^6.0.0 => 6.0.0
    gatsby-source-filesystem: ^5.0.0 => 5.0.0
    gatsby-transformer-json: ^5.0.0 => 5.0.0
    gatsby-transformer-sharp: ^5.0.0 => 5.0.0
  npmGlobalPackages:
    gatsby-cli: 5.7.0

maybe a swc parser error?