2015-07-17 18:20:38 -07:00
|
|
|
'use strict';
|
|
|
|
|
|
2017-12-11 23:52:46 +08:00
|
|
|
const path = require('path');
|
2015-08-18 21:31:32 -07:00
|
|
|
|
2019-08-08 17:46:35 -07:00
|
|
|
const babel = require('@babel/core');
|
2017-12-11 23:52:46 +08:00
|
|
|
const coffee = require('coffee-script');
|
2023-01-05 15:41:49 -05:00
|
|
|
const hermesParser = require('hermes-parser');
|
2015-07-17 18:20:38 -07:00
|
|
|
|
2017-12-11 23:52:46 +08:00
|
|
|
const tsPreprocessor = require('./typescript/preprocessor');
|
|
|
|
|
const createCacheKeyFunction = require('fbjs-scripts/jest/createCacheKeyFunction');
|
2024-02-06 15:03:36 +00:00
|
|
|
const {ReactVersion} = require('../../ReactVersions');
|
|
|
|
|
const semver = require('semver');
|
2015-09-22 17:40:04 -07:00
|
|
|
|
2017-12-11 23:52:46 +08:00
|
|
|
const pathToBabel = path.join(
|
2019-08-08 17:46:35 -07:00
|
|
|
require.resolve('@babel/core'),
|
|
|
|
|
'../..',
|
2017-04-05 16:47:29 +01:00
|
|
|
'package.json'
|
|
|
|
|
);
|
2019-09-13 15:50:25 -07:00
|
|
|
const pathToTransformInfiniteLoops = require.resolve(
|
|
|
|
|
'../babel/transform-prevent-infinite-loops'
|
|
|
|
|
);
|
Add pragma for feature testing: @gate (#18581)
* Add pragma for feature testing: @gate
The `@gate` pragma declares under which conditions a test is expected to
pass.
If the gate condition passes, then the test runs normally (same as if
there were no pragma).
If the conditional fails, then the test runs and is *expected to fail*.
An alternative to `it.experimental` and similar proposals.
Examples
--------
Basic:
```js
// @gate enableBlocksAPI
test('passes only if Blocks API is available', () => {/*...*/})
```
Negation:
```js
// @gate !disableLegacyContext
test('depends on a deprecated feature', () => {/*...*/})
```
Multiple flags:
```js
// @gate enableNewReconciler
// @gate experimental
test('needs both useEvent and Blocks', () => {/*...*/})
```
Logical operators (yes, I'm sorry):
```js
// @gate experimental && (enableNewReconciler || disableSchedulerTimeoutBasedOnReactExpirationTime)
test('concurrent mode, doesn\'t work in old fork unless Scheduler timeout flag is disabled', () => {/*...*/})
```
Strings, and comparion operators
No use case yet but I figure eventually we'd use this to gate on
different release channels:
```js
// @gate channel === "experimental" || channel === "modern"
test('works in OSS experimental or www modern', () => {/*...*/})
```
How does it work?
I'm guessing those last two examples might be controversial. Supporting
those cases did require implementing a mini-parser.
The output of the transform is very straightforward, though.
Input:
```js
// @gate a && (b || c)
test('some test', () => {/*...*/})
```
Output:
```js
_test_gate(ctx => ctx.a && (ctx.b || ctx.c, 'some test'), () => {/*...*/});
```
It also works with `it`, `it.only`, and `fit`. It leaves `it.skip` and
`xit` alone because those tests are disabled anyway.
`_test_gate` is a global method that I set up in our Jest config. It
works about the same as the existing `it.experimental` helper.
The context (`ctx`) argument is whatever we want it to be. I set it up
so that it throws if you try to access a flag that doesn't exist. I also
added some shortcuts for common gating conditions, like `old`
and `new`:
```js
// @gate experimental
test('experimental feature', () => {/*...*/})
// @gate new
test('only passes in new reconciler', () => {/*...*/})
```
Why implement this as a pragma instead of a runtime API?
- Doesn't require monkey patching built-in Jest methods. Instead it
compiles to a runtime function that composes Jest's API.
- Will be easy to upgrade if Jest ever overhauls their API or we switch
to a different testing framework (unlikely but who knows).
- It feels lightweight so hopefully people won't feel gross using it.
For example, adding or removing a gate pragma will never affect the
indentation of the test, unlike if you wrapped the test in a
conditional block.
* Compatibility with console error/warning tracking
We patch console.error and console.warning to track unexpected calls
in our tests. If there's an unexpected call, we usually throw inside
an `afterEach` hook. However, that's too late for tests that we
expect to fail, because our `_test_gate` runtime can't capture the
error. So I also check for unexpected calls inside `_test_gate`.
* Move test flags to dedicated file
Added some instructions for how the flags are set up and how to
use them.
* Add dynamic version of gate API
Receives same flags as the pragma.
If we ever decide to revert the pragma, we can codemod them to use
this instead.
2020-04-13 10:14:34 -07:00
|
|
|
const pathToTransformTestGatePragma = require.resolve(
|
|
|
|
|
'../babel/transform-test-gate-pragma'
|
|
|
|
|
);
|
Fix Jest cache for transform-react-version-pragma (#25712)
<!--
Thanks for submitting a pull request!
We appreciate you spending the time to work on these changes. Please
provide enough information so that others can review your pull request.
The three fields below are mandatory.
Before submitting a pull request, please make sure the following is
done:
1. Fork [the repository](https://github.com/facebook/react) and create
your branch from `main`.
2. Run `yarn` in the repository root.
3. If you've fixed a bug or added code that should be tested, add tests!
4. Ensure the test suite passes (`yarn test`). Tip: `yarn test --watch
TestName` is helpful in development.
5. Run `yarn test --prod` to test in the production environment. It
supports the same options as `yarn test`.
6. If you need a debugger, run `yarn debug-test --watch TestName`, open
`chrome://inspect`, and press "Inspect".
7. Format your code with
[prettier](https://github.com/prettier/prettier) (`yarn prettier`).
8. Make sure your code lints (`yarn lint`). Tip: `yarn linc` to only
check changed files.
9. Run the [Flow](https://flowtype.org/) type checks (`yarn flow`).
10. If you haven't already, complete the CLA.
Learn more about contributing:
https://reactjs.org/docs/how-to-contribute.html
-->
## Summary
Jest caching wasn't working correctly for
`transform-react-version-pragma`. One condition for including
`transform-react-version-pragma` is that `process.env.REACT_VERSION` is
set, but it wasn't included in the cache key computation. Thus local
test runs would only run without `transform-react-version-pragma`, if
jest runs weren't using the `-reactVersion` flag and then added it.
Inlined the `scripts/jest/devtools/preprocessor.js` file, because it
makes it more obvious that `process.env.REACT_VERSION` is used in
`scripts/jest/preprocessor.js`
<!--
Explain the **motivation** for making this change. What existing problem
does the pull request solve?
-->
## How did you test this change?
<!--
Demonstrate the code is solid. Example: The exact commands you ran and
their output, screenshots / videos if the pull request changes the user
interface.
How exactly did you verify that your PR solves the issue you wanted to
solve?
If you leave this empty, your PR will very likely be closed.
-->
Repro step:
- Clear jest cache
- node ./scripts/jest/jest-cli.js --build --project devtools
--release-channel=experimental --reactVersion 18.0
- node ./scripts/jest/jest-cli.js --build --project devtools
--release-channel=experimental
Before:
Jest cached the first run with `REACT_VERSION` set, so in the second run
`transform-react-version-pragma` is still there and runs only the
regression tests on old react versions.
After:
- The second run runs all tests and ignore `// @reactVersion` as
expected.
2022-11-28 15:14:34 -08:00
|
|
|
const pathToTransformReactVersionPragma = require.resolve(
|
|
|
|
|
'../babel/transform-react-version-pragma'
|
|
|
|
|
);
|
2024-07-23 15:51:23 -04:00
|
|
|
const pathToTransformLazyJSXImport = require.resolve(
|
|
|
|
|
'../babel/transform-lazy-jsx-import'
|
|
|
|
|
);
|
2019-08-08 17:46:35 -07:00
|
|
|
const pathToBabelrc = path.join(__dirname, '..', '..', 'babel.config.js');
|
2017-12-11 23:52:46 +08:00
|
|
|
const pathToErrorCodes = require.resolve('../error-codes/codes.json');
|
2015-09-22 17:40:04 -07:00
|
|
|
|
2024-02-06 15:03:36 +00:00
|
|
|
const ReactVersionTestingAgainst = process.env.REACT_VERSION || ReactVersion;
|
|
|
|
|
|
2017-12-11 23:52:46 +08:00
|
|
|
const babelOptions = {
|
2016-02-26 16:49:32 -08:00
|
|
|
plugins: [
|
2017-11-02 19:50:03 +00:00
|
|
|
// For Node environment only. For builds, Rollup takes care of ESM.
|
2019-08-08 17:46:35 -07:00
|
|
|
require.resolve('@babel/plugin-transform-modules-commonjs'),
|
2017-11-02 19:50:03 +00:00
|
|
|
|
2019-09-13 15:50:25 -07:00
|
|
|
pathToTransformInfiniteLoops,
|
Add pragma for feature testing: @gate (#18581)
* Add pragma for feature testing: @gate
The `@gate` pragma declares under which conditions a test is expected to
pass.
If the gate condition passes, then the test runs normally (same as if
there were no pragma).
If the conditional fails, then the test runs and is *expected to fail*.
An alternative to `it.experimental` and similar proposals.
Examples
--------
Basic:
```js
// @gate enableBlocksAPI
test('passes only if Blocks API is available', () => {/*...*/})
```
Negation:
```js
// @gate !disableLegacyContext
test('depends on a deprecated feature', () => {/*...*/})
```
Multiple flags:
```js
// @gate enableNewReconciler
// @gate experimental
test('needs both useEvent and Blocks', () => {/*...*/})
```
Logical operators (yes, I'm sorry):
```js
// @gate experimental && (enableNewReconciler || disableSchedulerTimeoutBasedOnReactExpirationTime)
test('concurrent mode, doesn\'t work in old fork unless Scheduler timeout flag is disabled', () => {/*...*/})
```
Strings, and comparion operators
No use case yet but I figure eventually we'd use this to gate on
different release channels:
```js
// @gate channel === "experimental" || channel === "modern"
test('works in OSS experimental or www modern', () => {/*...*/})
```
How does it work?
I'm guessing those last two examples might be controversial. Supporting
those cases did require implementing a mini-parser.
The output of the transform is very straightforward, though.
Input:
```js
// @gate a && (b || c)
test('some test', () => {/*...*/})
```
Output:
```js
_test_gate(ctx => ctx.a && (ctx.b || ctx.c, 'some test'), () => {/*...*/});
```
It also works with `it`, `it.only`, and `fit`. It leaves `it.skip` and
`xit` alone because those tests are disabled anyway.
`_test_gate` is a global method that I set up in our Jest config. It
works about the same as the existing `it.experimental` helper.
The context (`ctx`) argument is whatever we want it to be. I set it up
so that it throws if you try to access a flag that doesn't exist. I also
added some shortcuts for common gating conditions, like `old`
and `new`:
```js
// @gate experimental
test('experimental feature', () => {/*...*/})
// @gate new
test('only passes in new reconciler', () => {/*...*/})
```
Why implement this as a pragma instead of a runtime API?
- Doesn't require monkey patching built-in Jest methods. Instead it
compiles to a runtime function that composes Jest's API.
- Will be easy to upgrade if Jest ever overhauls their API or we switch
to a different testing framework (unlikely but who knows).
- It feels lightweight so hopefully people won't feel gross using it.
For example, adding or removing a gate pragma will never affect the
indentation of the test, unlike if you wrapped the test in a
conditional block.
* Compatibility with console error/warning tracking
We patch console.error and console.warning to track unexpected calls
in our tests. If there's an unexpected call, we usually throw inside
an `afterEach` hook. However, that's too late for tests that we
expect to fail, because our `_test_gate` runtime can't capture the
error. So I also check for unexpected calls inside `_test_gate`.
* Move test flags to dedicated file
Added some instructions for how the flags are set up and how to
use them.
* Add dynamic version of gate API
Receives same flags as the pragma.
If we ever decide to revert the pragma, we can codemod them to use
this instead.
2020-04-13 10:14:34 -07:00
|
|
|
pathToTransformTestGatePragma,
|
2019-08-14 19:04:43 -07:00
|
|
|
|
|
|
|
|
// This optimization is important for extremely performance-sensitive (e.g. React source).
|
|
|
|
|
// It's okay to disable it for tests.
|
2019-08-15 09:53:22 -07:00
|
|
|
[
|
|
|
|
|
require.resolve('@babel/plugin-transform-block-scoping'),
|
|
|
|
|
{throwIfClosureRequired: false},
|
|
|
|
|
],
|
2015-09-22 17:40:04 -07:00
|
|
|
],
|
|
|
|
|
retainLines: true,
|
|
|
|
|
};
|
2015-07-17 18:20:38 -07:00
|
|
|
|
|
|
|
|
module.exports = {
|
2023-01-31 08:25:05 -05:00
|
|
|
process: function (src, filePath) {
|
Update DevTools to use getCacheForType API (#20548)
DevTools was built with a fork of an early idea for how Suspense cache might work. This idea is incompatible with newer APIs like `useTransition` which unfortunately prevented me from making certain UX improvements. This PR swaps out the primary usage of this cache (there are a few) in favor of the newer `unstable_getCacheForType` and `unstable_useCacheRefresh` APIs. We can go back and update the others in follow up PRs.
### Messaging changes
I've refactored the way the frontend loads component props/state/etc to hopefully make it better match the Suspense+cache model. Doing this gave up some of the small optimizations I'd added but hopefully the actual performance impact of that is minor and the overall ergonomic improvements of working with the cache API make this worth it.
The backend no longer remembers inspected paths. Instead, the frontend sends them every time and the backend sends a response with those paths. I've also added a new "force" parameter that the frontend can use to tell the backend to send a response even if the component hasn't rendered since the last time it asked. (This is used to get data for newly inspected paths.)
_Initial inspection..._
```
front | | back
| -- "inspect" (id:1, paths:[], force:true) ---------> |
| <------------------------ "inspected" (full-data) -- |
```
_1 second passes with no updates..._
```
| -- "inspect" (id:1, paths:[], force:false) --------> |
| <------------------------ "inspected" (no-change) -- |
```
_User clicks to expand a path, aka hydrate..._
```
| -- "inspect" (id:1, paths:['foo'], force:true) ----> |
| <------------------------ "inspected" (full-data) -- |
```
_1 second passes during which there is an update..._
```
| -- "inspect" (id:1, paths:['foo'], force:false) ---> |
| <----------------- "inspectedElement" (full-data) -- |
```
### Clear errors/warnings transition
Previously this meant there would be a delay after clicking the "clear" button. The UX after this change is much improved.
### Hydrating paths transition
I also added a transition to hydration (expanding "dehyrated" paths).
### Better error boundaries
I also added a lower-level error boundary in case the new suspense operation ever failed. It provides a better "retry" mechanism (select a new element) so DevTools doesn't become entirely useful. Here I'm intentionally causing an error every time I select an element.
### Improved snapshot tests
I also migrated several of the existing snapshot tests to use inline snapshots and added a new serializer for dehydrated props. Inline snapshots are easier to verify and maintain and the new serializer means dehydrated props will be formatted in a way that makes sense rather than being empty (in external snapshots) or super verbose (default inline snapshot format).
2021-01-19 06:51:32 -08:00
|
|
|
if (filePath.match(/\.css$/)) {
|
|
|
|
|
// Don't try to parse CSS modules; they aren't needed for tests anyway.
|
2023-02-10 00:07:49 +08:00
|
|
|
return {code: ''};
|
Update DevTools to use getCacheForType API (#20548)
DevTools was built with a fork of an early idea for how Suspense cache might work. This idea is incompatible with newer APIs like `useTransition` which unfortunately prevented me from making certain UX improvements. This PR swaps out the primary usage of this cache (there are a few) in favor of the newer `unstable_getCacheForType` and `unstable_useCacheRefresh` APIs. We can go back and update the others in follow up PRs.
### Messaging changes
I've refactored the way the frontend loads component props/state/etc to hopefully make it better match the Suspense+cache model. Doing this gave up some of the small optimizations I'd added but hopefully the actual performance impact of that is minor and the overall ergonomic improvements of working with the cache API make this worth it.
The backend no longer remembers inspected paths. Instead, the frontend sends them every time and the backend sends a response with those paths. I've also added a new "force" parameter that the frontend can use to tell the backend to send a response even if the component hasn't rendered since the last time it asked. (This is used to get data for newly inspected paths.)
_Initial inspection..._
```
front | | back
| -- "inspect" (id:1, paths:[], force:true) ---------> |
| <------------------------ "inspected" (full-data) -- |
```
_1 second passes with no updates..._
```
| -- "inspect" (id:1, paths:[], force:false) --------> |
| <------------------------ "inspected" (no-change) -- |
```
_User clicks to expand a path, aka hydrate..._
```
| -- "inspect" (id:1, paths:['foo'], force:true) ----> |
| <------------------------ "inspected" (full-data) -- |
```
_1 second passes during which there is an update..._
```
| -- "inspect" (id:1, paths:['foo'], force:false) ---> |
| <----------------- "inspectedElement" (full-data) -- |
```
### Clear errors/warnings transition
Previously this meant there would be a delay after clicking the "clear" button. The UX after this change is much improved.
### Hydrating paths transition
I also added a transition to hydration (expanding "dehyrated" paths).
### Better error boundaries
I also added a lower-level error boundary in case the new suspense operation ever failed. It provides a better "retry" mechanism (select a new element) so DevTools doesn't become entirely useful. Here I'm intentionally causing an error every time I select an element.
### Improved snapshot tests
I also migrated several of the existing snapshot tests to use inline snapshots and added a new serializer for dehydrated props. Inline snapshots are easier to verify and maintain and the new serializer means dehydrated props will be formatted in a way that makes sense rather than being empty (in external snapshots) or super verbose (default inline snapshot format).
2021-01-19 06:51:32 -08:00
|
|
|
}
|
2015-08-18 21:31:32 -07:00
|
|
|
if (filePath.match(/\.coffee$/)) {
|
2023-02-10 00:07:49 +08:00
|
|
|
return {code: coffee.compile(src, {bare: true})};
|
2015-07-17 18:20:38 -07:00
|
|
|
}
|
2015-08-18 21:31:32 -07:00
|
|
|
if (filePath.match(/\.ts$/) && !filePath.match(/\.d\.ts$/)) {
|
2023-02-10 00:07:49 +08:00
|
|
|
return {code: tsPreprocessor.compile(src, filePath)};
|
2015-07-17 18:20:38 -07:00
|
|
|
}
|
2019-10-03 19:14:18 +02:00
|
|
|
if (filePath.match(/\.json$/)) {
|
2023-02-10 00:07:49 +08:00
|
|
|
return {code: src};
|
2019-10-03 19:14:18 +02:00
|
|
|
}
|
2017-10-26 15:15:24 +01:00
|
|
|
if (!filePath.match(/\/third_party\//)) {
|
2017-03-03 10:34:14 -08:00
|
|
|
// for test files, we also apply the async-await transform, but we want to
|
|
|
|
|
// make sure we don't accidentally apply that transform to product code.
|
2017-12-11 23:52:46 +08:00
|
|
|
const isTestFile = !!filePath.match(/\/__tests__\//);
|
2019-12-17 00:03:12 +00:00
|
|
|
const isInDevToolsPackages = !!filePath.match(
|
|
|
|
|
/\/packages\/react-devtools.*\//
|
|
|
|
|
);
|
2024-07-12 14:39:38 -04:00
|
|
|
const plugins = [].concat(babelOptions.plugins);
|
2023-06-22 09:33:05 +01:00
|
|
|
if (isTestFile && isInDevToolsPackages) {
|
Fix Jest cache for transform-react-version-pragma (#25712)
<!--
Thanks for submitting a pull request!
We appreciate you spending the time to work on these changes. Please
provide enough information so that others can review your pull request.
The three fields below are mandatory.
Before submitting a pull request, please make sure the following is
done:
1. Fork [the repository](https://github.com/facebook/react) and create
your branch from `main`.
2. Run `yarn` in the repository root.
3. If you've fixed a bug or added code that should be tested, add tests!
4. Ensure the test suite passes (`yarn test`). Tip: `yarn test --watch
TestName` is helpful in development.
5. Run `yarn test --prod` to test in the production environment. It
supports the same options as `yarn test`.
6. If you need a debugger, run `yarn debug-test --watch TestName`, open
`chrome://inspect`, and press "Inspect".
7. Format your code with
[prettier](https://github.com/prettier/prettier) (`yarn prettier`).
8. Make sure your code lints (`yarn lint`). Tip: `yarn linc` to only
check changed files.
9. Run the [Flow](https://flowtype.org/) type checks (`yarn flow`).
10. If you haven't already, complete the CLA.
Learn more about contributing:
https://reactjs.org/docs/how-to-contribute.html
-->
## Summary
Jest caching wasn't working correctly for
`transform-react-version-pragma`. One condition for including
`transform-react-version-pragma` is that `process.env.REACT_VERSION` is
set, but it wasn't included in the cache key computation. Thus local
test runs would only run without `transform-react-version-pragma`, if
jest runs weren't using the `-reactVersion` flag and then added it.
Inlined the `scripts/jest/devtools/preprocessor.js` file, because it
makes it more obvious that `process.env.REACT_VERSION` is used in
`scripts/jest/preprocessor.js`
<!--
Explain the **motivation** for making this change. What existing problem
does the pull request solve?
-->
## How did you test this change?
<!--
Demonstrate the code is solid. Example: The exact commands you ran and
their output, screenshots / videos if the pull request changes the user
interface.
How exactly did you verify that your PR solves the issue you wanted to
solve?
If you leave this empty, your PR will very likely be closed.
-->
Repro step:
- Clear jest cache
- node ./scripts/jest/jest-cli.js --build --project devtools
--release-channel=experimental --reactVersion 18.0
- node ./scripts/jest/jest-cli.js --build --project devtools
--release-channel=experimental
Before:
Jest cached the first run with `REACT_VERSION` set, so in the second run
`transform-react-version-pragma` is still there and runs only the
regression tests on old react versions.
After:
- The second run runs all tests and ignore `// @reactVersion` as
expected.
2022-11-28 15:14:34 -08:00
|
|
|
plugins.push(pathToTransformReactVersionPragma);
|
2022-05-11 09:01:05 -07:00
|
|
|
}
|
2024-02-05 23:07:41 -05:00
|
|
|
|
2024-02-06 15:03:36 +00:00
|
|
|
// This is only for React DevTools tests with React 16.x
|
|
|
|
|
// `react/jsx-dev-runtime` and `react/jsx-runtime` are included in the package starting from v17
|
2025-09-15 15:31:58 +02:00
|
|
|
// Technically 16.14 and 15.7 have the new runtime but we're not testing those versions.
|
|
|
|
|
if (
|
|
|
|
|
semver.gte(ReactVersionTestingAgainst, '15.0.0') &&
|
|
|
|
|
semver.lt(ReactVersionTestingAgainst, '17.0.0')
|
|
|
|
|
) {
|
|
|
|
|
plugins.push(
|
|
|
|
|
[
|
|
|
|
|
require.resolve('@babel/plugin-transform-react-jsx'),
|
|
|
|
|
{runtime: 'classic'},
|
|
|
|
|
],
|
|
|
|
|
require.resolve('@babel/plugin-transform-react-jsx-source')
|
|
|
|
|
);
|
|
|
|
|
} else {
|
2024-02-06 15:03:36 +00:00
|
|
|
plugins.push([
|
|
|
|
|
process.env.NODE_ENV === 'development'
|
|
|
|
|
? require.resolve('@babel/plugin-transform-react-jsx-development')
|
|
|
|
|
: require.resolve('@babel/plugin-transform-react-jsx'),
|
|
|
|
|
// The "automatic" runtime corresponds to react/jsx-runtime. "classic"
|
|
|
|
|
// would be React.createElement.
|
|
|
|
|
{runtime: 'automatic'},
|
|
|
|
|
]);
|
|
|
|
|
}
|
2024-02-05 23:07:41 -05:00
|
|
|
|
2024-07-23 15:51:23 -04:00
|
|
|
plugins.push(pathToTransformLazyJSXImport);
|
|
|
|
|
|
2023-01-05 15:41:49 -05:00
|
|
|
let sourceAst = hermesParser.parse(src, {babel: true});
|
2023-02-10 00:07:49 +08:00
|
|
|
return {
|
|
|
|
|
code: babel.transformFromAstSync(
|
|
|
|
|
sourceAst,
|
|
|
|
|
src,
|
|
|
|
|
Object.assign(
|
|
|
|
|
{filename: path.relative(process.cwd(), filePath)},
|
|
|
|
|
babelOptions,
|
|
|
|
|
{
|
|
|
|
|
plugins,
|
|
|
|
|
sourceMaps: process.env.JEST_ENABLE_SOURCE_MAPS
|
|
|
|
|
? process.env.JEST_ENABLE_SOURCE_MAPS
|
|
|
|
|
: false,
|
|
|
|
|
}
|
|
|
|
|
)
|
|
|
|
|
).code,
|
|
|
|
|
};
|
2015-07-17 18:20:38 -07:00
|
|
|
}
|
2023-02-10 00:07:49 +08:00
|
|
|
return {code: src};
|
2015-07-17 18:20:38 -07:00
|
|
|
},
|
2015-09-22 17:40:04 -07:00
|
|
|
|
Fix Jest cache for transform-react-version-pragma (#25712)
<!--
Thanks for submitting a pull request!
We appreciate you spending the time to work on these changes. Please
provide enough information so that others can review your pull request.
The three fields below are mandatory.
Before submitting a pull request, please make sure the following is
done:
1. Fork [the repository](https://github.com/facebook/react) and create
your branch from `main`.
2. Run `yarn` in the repository root.
3. If you've fixed a bug or added code that should be tested, add tests!
4. Ensure the test suite passes (`yarn test`). Tip: `yarn test --watch
TestName` is helpful in development.
5. Run `yarn test --prod` to test in the production environment. It
supports the same options as `yarn test`.
6. If you need a debugger, run `yarn debug-test --watch TestName`, open
`chrome://inspect`, and press "Inspect".
7. Format your code with
[prettier](https://github.com/prettier/prettier) (`yarn prettier`).
8. Make sure your code lints (`yarn lint`). Tip: `yarn linc` to only
check changed files.
9. Run the [Flow](https://flowtype.org/) type checks (`yarn flow`).
10. If you haven't already, complete the CLA.
Learn more about contributing:
https://reactjs.org/docs/how-to-contribute.html
-->
## Summary
Jest caching wasn't working correctly for
`transform-react-version-pragma`. One condition for including
`transform-react-version-pragma` is that `process.env.REACT_VERSION` is
set, but it wasn't included in the cache key computation. Thus local
test runs would only run without `transform-react-version-pragma`, if
jest runs weren't using the `-reactVersion` flag and then added it.
Inlined the `scripts/jest/devtools/preprocessor.js` file, because it
makes it more obvious that `process.env.REACT_VERSION` is used in
`scripts/jest/preprocessor.js`
<!--
Explain the **motivation** for making this change. What existing problem
does the pull request solve?
-->
## How did you test this change?
<!--
Demonstrate the code is solid. Example: The exact commands you ran and
their output, screenshots / videos if the pull request changes the user
interface.
How exactly did you verify that your PR solves the issue you wanted to
solve?
If you leave this empty, your PR will very likely be closed.
-->
Repro step:
- Clear jest cache
- node ./scripts/jest/jest-cli.js --build --project devtools
--release-channel=experimental --reactVersion 18.0
- node ./scripts/jest/jest-cli.js --build --project devtools
--release-channel=experimental
Before:
Jest cached the first run with `REACT_VERSION` set, so in the second run
`transform-react-version-pragma` is still there and runs only the
regression tests on old react versions.
After:
- The second run runs all tests and ignore `// @reactVersion` as
expected.
2022-11-28 15:14:34 -08:00
|
|
|
getCacheKey: createCacheKeyFunction(
|
|
|
|
|
[
|
|
|
|
|
__filename,
|
|
|
|
|
pathToBabel,
|
|
|
|
|
pathToBabelrc,
|
|
|
|
|
pathToTransformInfiniteLoops,
|
|
|
|
|
pathToTransformTestGatePragma,
|
|
|
|
|
pathToTransformReactVersionPragma,
|
2024-07-23 15:51:23 -04:00
|
|
|
pathToTransformLazyJSXImport,
|
Fix Jest cache for transform-react-version-pragma (#25712)
<!--
Thanks for submitting a pull request!
We appreciate you spending the time to work on these changes. Please
provide enough information so that others can review your pull request.
The three fields below are mandatory.
Before submitting a pull request, please make sure the following is
done:
1. Fork [the repository](https://github.com/facebook/react) and create
your branch from `main`.
2. Run `yarn` in the repository root.
3. If you've fixed a bug or added code that should be tested, add tests!
4. Ensure the test suite passes (`yarn test`). Tip: `yarn test --watch
TestName` is helpful in development.
5. Run `yarn test --prod` to test in the production environment. It
supports the same options as `yarn test`.
6. If you need a debugger, run `yarn debug-test --watch TestName`, open
`chrome://inspect`, and press "Inspect".
7. Format your code with
[prettier](https://github.com/prettier/prettier) (`yarn prettier`).
8. Make sure your code lints (`yarn lint`). Tip: `yarn linc` to only
check changed files.
9. Run the [Flow](https://flowtype.org/) type checks (`yarn flow`).
10. If you haven't already, complete the CLA.
Learn more about contributing:
https://reactjs.org/docs/how-to-contribute.html
-->
## Summary
Jest caching wasn't working correctly for
`transform-react-version-pragma`. One condition for including
`transform-react-version-pragma` is that `process.env.REACT_VERSION` is
set, but it wasn't included in the cache key computation. Thus local
test runs would only run without `transform-react-version-pragma`, if
jest runs weren't using the `-reactVersion` flag and then added it.
Inlined the `scripts/jest/devtools/preprocessor.js` file, because it
makes it more obvious that `process.env.REACT_VERSION` is used in
`scripts/jest/preprocessor.js`
<!--
Explain the **motivation** for making this change. What existing problem
does the pull request solve?
-->
## How did you test this change?
<!--
Demonstrate the code is solid. Example: The exact commands you ran and
their output, screenshots / videos if the pull request changes the user
interface.
How exactly did you verify that your PR solves the issue you wanted to
solve?
If you leave this empty, your PR will very likely be closed.
-->
Repro step:
- Clear jest cache
- node ./scripts/jest/jest-cli.js --build --project devtools
--release-channel=experimental --reactVersion 18.0
- node ./scripts/jest/jest-cli.js --build --project devtools
--release-channel=experimental
Before:
Jest cached the first run with `REACT_VERSION` set, so in the second run
`transform-react-version-pragma` is still there and runs only the
regression tests on old react versions.
After:
- The second run runs all tests and ignore `// @reactVersion` as
expected.
2022-11-28 15:14:34 -08:00
|
|
|
pathToErrorCodes,
|
|
|
|
|
],
|
|
|
|
|
[
|
|
|
|
|
(process.env.REACT_VERSION != null).toString(),
|
|
|
|
|
(process.env.NODE_ENV === 'development').toString(),
|
|
|
|
|
]
|
|
|
|
|
),
|
2015-07-17 18:20:38 -07:00
|
|
|
};
|
