[NullVoxPopuli]

Adds a configFile option, so parallel works with Babel configs that contain functions.

babel({
  parallel: true,
  configFile: path.resolve(import.meta.dirname, 'babel.config.js'),
})

Why

parallel (#139) sends the Babel options to each worker, so plugins must be referenced by name.
Many real configs can't do that.
For example, Ember apps build plugin objects and template transforms from functions at config time.

A config file path is just a string.
Each worker passes it to Babel, and Babel loads the file inside that worker.
@rollup/plugin-babel's parallel relies on the same approach.

Changes

• transformWithBabel forwards configFile instead of always passing false. babelrc stays false.
• applyToEnvironment no longer disables the plugin when the config file is the only source of plugins.
• When configFile is set, the transform filter skips the Rolldown preset filters, the same as when plugins is set. The file can apply to any module.
• README: documents the option, and updates the note that said config files are never loaded.

Alternatives explored

• A preset path pointing at the config file. Babel rejects preset files that export an object, and most config files export an object.
• A wrapper preset that imports the config. This works, but every user has to write the wrapper. It also changes plugin order when the config sits next to inline plugins.

Tests

• The config file loads in serial mode and with parallel: 2. The fixture config imports a plugin function.
• Inline plugins merge on top of the config file.
• In a Vite build with only configFile, the plugin still runs. This test fails without the applyToEnvironment change.
• Without configFile, babel.config.* in cwd is still ignored.
• Filter unit test: configFile falls back to the base filter.

🤖 Generated with Claude Code