Allow CJS ava.config.js

[billyjanitsch]

Description

I noticed that #1761 landed requiring ava.config.js to use ESM (export default rather than module.exports =). I read through the thread, and I guess I can understand wanting to support ESM, but what was the motivation for making it a requirement?

Most other libraries only support CJS configs, and I don't know of any that only allow ESM. It seems odd to require AVA's config to be written differently than all other config files in a typical repo.

[novemberborn]

It's an aversion from having too many ways of specifying config. Though perhaps odd at first, hopefully it's actually fine in practice. Let's use this issue to see if there are any problems and then we can add support for module.exports = {}.

[billyjanitsch]

It's an aversion from having too many ways of specifying config.

I have the same aversion, but from the perspective of a user using multiple tools in projects. I try to write my config files similarly to each other, so that they're easy to write, read, and modify. This becomes difficult when tools have divergent config formats.

So, from my perspective, ESM is a different way of specifying config, in that it's different from other tools, e.g. webpack, Babel, postcss, ESLint, stylelint, husky.

(That's why I'm a big fan of cosmiconfig, which is already used by many of the above -- by default, it supports a well-known, conventional set of formats which strike a good balance between user flexibility and complexity. It also reduces the burden on module authors to implement config lookup/loading, and provides consistent lookup/loading behavior between tools.)

I understand the tradeoff on simplicity, and I know that @sindresorhus has a strong preference for it. But if AVA is determined to support a single format, would you consider only supporting CJS? I'd think this would be the expected behavior at least until ESM is widely embraced in node (whether via esm, .mjs, or something else). Until then, this doesn't seem like a useful divergence.

[billyjanitsch]

Thanks for the discussion, by the way -- thrilled to be getting file-based config in any case.

[sindresorhus]

I don't really see the problem here. AVA has had built-in ESM support for years, so AVA users are used to using it. Extending it to the config makes sense in that way.

[cantremember]

on a possibly related note ... i nearly had had to downgrade my package.json's 'esm' configuration from { mode: "strict" } to "auto" because

• (at least according to the documentation I have read) there is no ava --config <CONFIG-FILE> CLI option,
• the file must be named 'ava.config.js'
• "strict" enforces an '.mjs' extension on files which use ESM syntax

if a CSJ export was supported, this wouldn't be an issue. fortunately i have the fallback to use the { ava } configuration option in package.json -- and that allows me to keep "strict"

on a related but tangential note, i have (so far) had no success in telling ava to glob for 'test/ava/*.mjs'

[x] Couldn't find any files to test

i have just started to integrate ava, so i could be making foolish mistakes / not RTFM properly

[novemberborn]

@cantremember thanks for the report. I suspect this is an issue with esm itself. I've opened standard-things/esm#501.

[vjpr]

I'm trying to use require.resolve in the config and getting require is not defined. Is this related, and is there a workaround?

[novemberborn]

@vjpr I imagine it is, yea.

What are you hoping to achieve?

esm does expose an import.meta object I believe.

[vjpr]

I need to require.resolve a babel plugin, because its trying to resolve from the project root, and I want it to resolve in a monorepo subpackage.

[novemberborn]

It's not ideal but perhaps you could use https://www.npmjs.com/package/resolve-from?

Or maybe it's possible to provide a relative path to the plugin? Assuming this goes into AVA's Babel pipeline, I'd expect it to be resolved relative to the project directory, so you should be able to reference the subpackage.

[vjpr]

I'll try resolve-from. Why is require.resolve not available though?

[novemberborn]

@vjpr I reckon esm (which we use to load the ava.config.js files) masks it.