Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Version 11.x Discussion #139

Closed
Xunnamius opened this issue Jan 16, 2023 · 9 comments
Closed

Version 11.x Discussion #139

Xunnamius opened this issue Jan 16, 2023 · 9 comments

Comments

@Xunnamius
Copy link
Collaborator

Xunnamius commented Jan 16, 2023

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:

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 Xunnamius pinned this issue Jan 16, 2023
@layershifter
Copy link

layershifter commented Jan 18, 2023

@Xunnamius amazing release ❤️ I have used it to fix tests on Windows (microsoft/griffel#318) and to test a preset (microsoft/griffel#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',
      },

Xunnamius added a commit to Xunnamius/babel-plugin-tester that referenced this issue Jan 18, 2023
Xunnamius added a commit that referenced this issue Jan 18, 2023
### [11.0.1](v11.0.0...v11.0.1) (2023-01-18)

#### 🪄 Fixes

* **src:** ensure deprecated `config` option is still supported by `prettierFormatter` ([e48badf](e48badf)) <sup>closes [#139](https://github.com/babel-utils/babel-plugin-tester/issues/139)</sup>
@Xunnamius
Copy link
Collaborator Author

@layershifter Nice catch! Should be fixed in 11.0.1. Thanks for the report :)

@SimenB
Copy link

SimenB commented Jan 23, 2023

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'
}

import { isNativeError } from 'node:util/types';

Not sure how that got past CI?

@Xunnamius
Copy link
Collaborator Author

Xunnamius commented Jan 23, 2023

@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.

@SimenB
Copy link

SimenB commented Jan 24, 2023

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!

@ulivz
Copy link

ulivz commented Nov 7, 2023

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;
  }
}

@Xunnamius
Copy link
Collaborator Author

Xunnamius commented Nov 9, 2023

Interesting, no reason comes to mind why that wouldn't work. I'll investigate this this weekend.

@Xunnamius
Copy link
Collaborator Author

Xunnamius commented Jan 20, 2024

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.

@Xunnamius
Copy link
Collaborator Author

Xunnamius commented Mar 13, 2024

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.

@Xunnamius Xunnamius unpinned this issue Mar 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants