Version 11.x Discussion
Hello! After nearly two years, the 11.0.0 version of babel-plugin-tester has been released 🎉🎉, and with it comes a bevy of improvements bringing the project up to date with the latest and greatest in the JavaScript ecosystem:
- ESM support
- Windows and WSL support
- First-class support for fixtures alongside test objects
- Built-in TypeScript support (no need for external
@types/babel-plugin-testerpackage) - Explicit Vitest,
node:test, and Jasmine support with documented examples - Built-in debug support
- Support for executing the results of transformations
- Support for configuring tests via environment variables
- Support for setup and teardown functions that run in a consistent order
- Support for testing presets as well as plugins
- Support for custom plugin and preset run order
- And more!
To ensure as smooth an experience as possible, preserving backwards compatibility was a priority for this release. The vast majority of babel-plugin-tester users should be able to migrate to the latest version without incident. However, if you notice any BC-breaking changes or have any questions or suggestions, feel free to leave a comment here or, if you encounter a problem, open a new issue.
I'll keep this issue pinned until the next minor release. Happy testing!
@Xunnamius amazing release ❤️ I have used it to fix tests on Windows (https://github.com/microsoft/griffel/pull/318) and to test a preset (https://github.com/microsoft/griffel/pull/309).
However, if you notice any BC-breaking changes or have any questions or suggestions, feel free to leave a comment here or, if you encounter a problem, open a new issue.
I don't see it documented, but there was a BC in prettierFormatter:
prettierFormatter(code, {
- config: {
+ prettierOptions: {
...prettierConfig,
parser: 'typescript',
},
@layershifter Nice catch! Should be fixed in 11.0.1. Thanks for the report :)
I'm trying to upgrade, but I'm getting Cannot find module 'node:util/types' from 'node_modules/babel-plugin-tester/dist/plugin-tester.js' on node 14.
$ node
Welcome to Node.js v14.20.0.
Type ".help" for more information.
> require('node:util/types')
Uncaught Error [ERR_UNKNOWN_BUILTIN_MODULE]: No such built-in module: node:util/types
at new NodeError (internal/errors.js:322:7)
at Function.Module._load (internal/modules/cjs/loader.js:753:13)
at Module.require (internal/modules/cjs/loader.js:974:19)
at require (internal/modules/cjs/helpers.js:101:18)
at REPL1:1:1
at Script.runInThisContext (vm.js:134:12)
at REPLServer.defaultEval (repl.js:566:29)
at bound (domain.js:421:15)
at REPLServer.runBound [as eval] (domain.js:432:12)
at REPLServer.onLine (repl.js:909:10) {
code: 'ERR_UNKNOWN_BUILTIN_MODULE'
}
https://github.com/babel-utils/babel-plugin-tester/blob/6c49f01eb8475fe014d0f68a0e34b8cdbc92e07e/src/plugin-tester.ts#L6
Not sure how that got past CI?
@SimenB Thanks for the report! I don't have access to set this repo's secrets, so the CI/CD setup a bit more of a manual effort than it should be for now, but I'm working on it.
The problem is fixed in 11.0.2, which should be correctly tested against all maintained node versions on both Windows and Linux.
I don't have access to set this repo's secrets, so the CI/CD setup a bit more of a manual effort than it should be for now, but I'm working on it.
Ah, gotcha 👍
The problem is fixed in 11.0.2
Can confirm it works, thanks!
Will 11 supports custom env for each fixture?
Currently I tried following options.js but it doesn't work:
/**
* @type {import('babel-plugin-tester').FixtureOptions}
*/
module.exports = {
only: true,
setup() {
process.env.BABEL_8_BREAKING = '1';
},
teardown() {
delete process.env.BABEL_8_BREAKING;
}
}
Interesting, no reason comes to mind why that wouldn't work. I'll investigate this ~~this weekend~~.
Hmm, I've thought about this more and decided that this use case is sufficiently covered by hooks like Jest's beforeEach and afterEach. If anyone has a use case where this wouldn't work, feel free to open an issue :)
(old comment)
Now that I'm testing babel 8 compat myself, I think I have a firmer grasp on what you were going for here. My current solution is to run pluginTester in different test files, overriding process.env in a beforeEach hook where necessary, where each file targets a different directory of fixtures. I agree a per- fixture/test environment variable override sounds like the more elegant solution here.
Perhaps something like:
/**
* @type {import('babel-plugin-tester').FixtureOptions}
*/
module.exports = {
only: true,
env: {
BABEL_8_BREAKING: '1'
}
}
Where env would augment process.env only for the duration of the babel.transformAsync/babel.transform function's execution:
const transformer = babel.transformAsync || babel.transform;
const oldProcessEnv = process.env;
process.env = Object.assign({}, oldProcessEnv, module.exports.env);
const { code: transformedCode } = (await transformer(...parameters)) || {};
process.env = oldProcessEnv;
return transformedCode;
This working will depend on how early Babel checks process.env.
I'm ambivalent on also forwarding any environment overrides to the VM context running the exec options. Right now, it works like this:
// Test suite passes
pluginTester({
plugin: /* ... */,
setup() {
expect(process.env.NEW_ENV_VAR).toBeUndefined();
process.env.NEW_ENV_VAR = '1';
},
teardown() {
expect(process.env.NEW_ENV_VAR).toBe('1');
delete process.env.NEW_ENV_VAR;
},
tests: []
});
// Test suite fails
pluginTester({
plugin: /* ... */'',
setup() {
expect(process.env.NEW_ENV_VAR).toBeUndefined();
process.env.NEW_ENV_VAR = '1';
},
teardown() {
expect(process.env.NEW_ENV_VAR).toBe('1');
delete process.env.NEW_ENV_VAR;
},
tests: [
// Expectation fails
{ exec: 'expect(process.env.NEW_ENV_VAR).toBe("1")' },
// Expectation fails
{ exec: `expect(${process.env.NEW_ENV_VAR}).toBe(1)` }
]
});
Which I think is fine, so I'll leave that be for now.
With prettier@3 forcing downstream adoption of their async interface, the next babel-plugin-tester version will bump major to 12. Along with dropping default export support and adding babel 8 support (and closing this issue), I'll add support for env and rawOutput as well.
With the next major version coming, this discussion thread has run its course. If anyone has any issues moving forward, please open a new issue.