How to control babel cache from a plugin?

[pladaria]

We use a babel plugin to apply translations to JS code. Translation files are read by the plugin and aren't part of the JS bundles.

When those files change, babel doesn't notice it and uses the cached data on following builds, so we don't get updated translations.

Is there any way, from the plugin side, to give babel a hash o set a cacheBust property to control the cache?

[JLHwung]

You can call api.addExternalDependency(filename: string) from the plugin, tools like @babel/cli or babel-loader will respect such external dependencies.

[pladaria]

Is there any documentation about this?

[pladaria]

Where does that api object come from? I see no mention to it in the plugin handbook:
https://github.com/jamiebuilds/babel-handbook/blob/master/translations/en/plugin-handbook.md
This document is linked from the official babel doc

[JLHwung]

The api object is injected as the first parameter of your Babel plugin factory:

// My Babel plugin
export default function (api) {
  api.addExternalDependency("foo.i18n");
  return {
    name: "plugin-name",
    visitor: {
      // plugin visitor
    }
  }
}

In https://github.com/jamiebuilds/babel-handbook/blob/master/translations/en/plugin-handbook.md#writing-your-first-babel-plugin, it is phrased as "the babel object". Actually it includes the Plugin API and the babel object.

babel/packages/babel-core/src/config/helpers/config-api.ts

Line 43 in f9fbc25

export type PluginAPI = {

[pladaria]

Ok, I called that parameter babel (instead of api). Btw, the addExternalDependency function seems to be missing in current type definitions.

I added that call but then the compilation seems to get stuck:

It stays there, at 15% forever (using @babel/core 7.20.12)

[JLHwung]

That seems like a bug. Does the external dependency rely on babel-loader? If not, can you provide a reproduction repo?

[pladaria]

The external dependency is just a json file (basically a map tokens => translations for several locales).
The plugin reads it with a fs.readFileSync.

In our webpack config we use thread-loader, for example:

                {
                    test: /\.(ts|tsx)$/,
                    include: [SRC_PATH, join(BASE_PATH, 'api_modules')],
                    use: [
                        'thread-loader',
                        {
                            loader: 'babel-loader',
                            options: {
                                cacheDirectory: true,
                                envName: ifDevServer('dev-server'),
                                configFile: require.resolve('../babel.config.js'),
                            },
                        },
                    ],
                },
               // more similar rules for monorepo packages or additional modules

I will try to setup a reproduction repository, although our setup is quite complex

[JLHwung]

Does the json file exist at compile time? Under the hood api.addExternalDependency() will add any dependencies to the externalDependencies set returned from babel.transform, and then babel-loader calls loaderContext.addDependency provided by webpack. loaderContext.addDependency only supports existing files.

[pladaria]

Yes, the file exists. It is being generated before executing webpack.