RFC: removing Babel

[chris-schra]

Dear All,

I experimented a bit because on my corporate-bloated notebook payload takes a while to start.

I've already migrated to esbuild-loader which drops build time 3x but there's one last thing: in load and index there's a "hard" require of babel/register.

My suggestion - if anyone is interested - is, to add a config flag like experimentalEsbuild?:boolean that would patch the webpack config and skip the requires of babel (drops time "Starting Payload..." to "Connected to Mongo Server successfully..."

With babel (only talking about the startup time with local:false):

[09:03:17] INFO (payload): Starting Payload...
[09:03:29] INFO (payload): Connected to Mongo server successfully!

No babel:

[09:04:29] INFO (payload): Starting Payload...
[09:04:33] INFO (payload): Connected to Mongo server successfully!

For reference, this is my working ESBuild config:

const withEsBuild = (config: Configuration) => {
  const originalRule = config.module.rules[0];
  const jsRule: Partial<RuleSetRule> = {};
  const tsRule: Partial<RuleSetRule> = {};
  Object.assign(jsRule, originalRule);
  Object.assign(tsRule, originalRule);
  jsRule.test = /\.jsx?$/;
  jsRule.use = [
    {
      loader: "esbuild-loader",
      options: {
        loader: "jsx",
        target: "es2015",
      },
    },
  ];

  tsRule.test = /\.tsx?$/;
  tsRule.use = [
    {
      loader: "esbuild-loader",
      options: {
        loader: "tsx",
        target: "es2015", 
      },
    },
  ];
  config.module.rules = [jsRule, tsRule, ...config.module.rules.slice(1)];
};

export default buildConfig({
  admin: {
    // ...
    webpack: (config) => {
      withEsBuild(config);

      config.cache = {
        type: "filesystem",
        allowCollectingMemory: true,
      };

      config.output.clean = true;
      config.optimization = {
        splitChunks: {
          chunks: "async",
          minSize: 20000,
          minRemainingSize: 0,
          minChunks: 1,
          maxAsyncRequests: 30,
          maxInitialRequests: 30,
          enforceSizeThreshold: 50000,
          cacheGroups: {
            defaultVendors: {
              test: /[\\/]node_modules[\\/]/,
              priority: -10,
              reuseExistingChunk: true,
            },
            default: {
              minChunks: 2,
              priority: -20,
              reuseExistingChunk: true,
            },
          },
        },
      };

      return config;
    },
  },
 // ...
});

[chris-schra]

anyone? I'd create a PR but only if there's a chance it could get merged :D

[jmikrut]

Hey @chris-schra — I think we would be very open to modifying our Webpack config to improve its performance, although removing Babel will have a lot of consequences and is not going to be a straightforward thing to do.

Our Payload config supports TypeScript, JSX, etc and should be able to be imported into any Node environment. This means that it needs to go through Babel or similar to ensure it can be parsed, even in vanilla JS / node environments.

We have a fair amount of things in-flight for our upcoming 1.0 release at the moment, but I am happy to help here in a few months once we have our current tasks completed.

PS - now that the three co-founders are all on Payload full-time, our velocity has increased a TON. :)

[chris-schra]

Thanks @jmikrut , I actually run Payload (at least in dev environment) w/o Babel atm. ESBuild is meant as modern replacement for babel.

In #721 I wrote about a "two-step build". And that's actually what I do:

• first step is to build my code, including payload.config.ts, via tsc (will replace that later, too, I guess) to /lib
• now I have CJS in /lib, of course including a now-transpiled payload.config.js
• second step is cross-env PAYLOAD_CONFIG_PATH=./lib/payload.config.js payload build
• that outputs CJS to /build

Now I simply run it with node ./build/index.js

Haven't found any issues yet, tbh, and it's blazing-fast

[jmikrut]

@chris-schra this is amazing.

I plan to revisit this thread with the team after our 1.0 release, but I am super interested in this move.

Let's make it happen!

[torbjorn-kvist]

@chris-schra Have to ask, do you have a public repository of the changes you did with ESBuild and the "two step build" or any spare time to make on public as a reference?

We are looking into using PayloadCMS at our company and looking a bit on how to improve the "cold start".

[mvarendorff]

Hey thread! I have been noticing the slow starts (granted, not 12+ seconds, but around 4 which coming from React+Vite and Flutter feels like eternity) recently and found this discussion after some research. With Payload now being past 1.0, is this something that is planned or on the horizon anytime soon? The discussion doesn't have any labels so it's not on the roadmap for this year? Would you still accept pull requests in that direction?

And are there ideas to go even beyond just removing babel? I am not super familiar with the widespread tooling for JS transpilation / bundling but coming from the frontend world, there are really good and fast alternatives to webpack. Could that possibly be replaced all-together?

[jmikrut]

Hey there! We removed Babel already 👍

If you are using ts-node in development, you can get a big speed boost right now by enabling swc.

Webpack itself is still slow though. We ditched all babel loaders for swc loaders but are still handicapped by Webpack.

Once Turbopack gets stable, and can support all the features we rely on, we will be moving to that! And that's when the actual webpack side of things will become lightning fast 😎

Hopefully that's very soon. In the meantime, make sure you're using swc with ts-node!