-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
Add build-time code exclusion using code fencing #12060
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
use the example luke 🧙♂️
generally good |
Builds ready [6d9512e]
Page Load Metrics (371 ± 18 ms)
|
Builds ready [6f97fa6]
Page Load Metrics (381 ± 20 ms)
|
Builds ready [ba99fcd]
Page Load Metrics (379 ± 20 ms)
|
bd95c35
to
7f2e40a
Compare
Builds ready [7f2e40a]
Page Load Metrics (416 ± 28 ms)
|
7f2e40a
to
f6126d1
Compare
4af5572
to
a950ea2
Compare
ec6d0cf
to
09ca404
Compare
Builds ready [f74378d]
Page Load Metrics (404 ± 21 ms)
|
Builds ready [b0c42ec]
Page Load Metrics (361 ± 18 ms)
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks really good and my testing was successful. Well done, and very quickly at that!
'<rootDir>/shared/**/?(*.)+(test).js', | ||
], | ||
// TODO: enable resetMocks | ||
// resetMocks: true, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will this take place in a later update?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
resetMocks
was already not enabled, and enabling it caused errors. I'm just highlighting that we should enable it here!
cb1f59a
to
efd8cd3
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm 🔥
setupFiles: ['<rootDir>/test/setup.js', '<rootDir>/test/env.js'], | ||
setupFilesAfterEnv: ['<rootDir>/test/jest/setup.js'], | ||
testMatch: ['<rootDir>/ui/**/*.test.js', '<rootDir>/shared/**/*.test.js'], | ||
testTimeout: 2500, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks new - is this the default setting?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We bumped the timeout at one point in the module template: https://github.com/MetaMask/metamask-module-template/blob/main/jest.config.js#L26
test/run-jest.sh
Outdated
# For storing PIDs of subshells | ||
PIDS=(0 0) | ||
|
||
yarn 'jest' '--config=./jest.config.js' "$@" & PIDS[0]=$! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This pattern seems questionable 🤔 This means if one process fails, the other will keep going and there will be no way to stop it. Sounds like a pain.
We have a package that is supposed to do this sort of thing for us: concurrently
. I don't think it works correctly in all cases, but it might work more often than this.
I think we could scrap this whole script and call concurrently
directly from the npm script.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This means if one process fails, the other will keep going and there will be no way to stop it. Sounds like a pain.
This is an intentional feature, not a bug! The idea being that, in CI, you want to know of all unit test failures, not just the ones for a particular config. This is an attempt to replicate what the Jest projects
feature does, which is to run all tests for every project and then print the complete results.
If developing locally, the tests for a particular config can be run by doing yarn jest --config=PATH_TO_CONFIG
.
On the topic of using concurrently
, that seems like a good idea, since it appears to be a well-maintained tool that does exactly what I'm trying to do. We may still have to keep this script in order to do something like yarn test:unit:jest --watch
and pass the --watch
argument to both invocations of jest
. That's what the "$@"
is about in the Bash script.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just to be clear, when I say "there is no way to stop it", what I mean is that the interrupt signal no longer halts the script. I certainly hope disabling CTRL+C wasn't intentional! It's incredibly frustrating when scripts can't be halted.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
... I tested this, and it works 🤔 I guess it's because these tests don't spawn child processes? This was a struggle to get working with the e2e tests. Our attempts to combine tests just with bash resulted in them continuing on after interrupting the main process.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I decided to go with concurrently
but keep the bash script. I went for concurrently
because a tool we're already using is probably better than a weird Bash loop-and-wait
implementation. However, I invoke concurrently
in the .sh
file to preserve the ability to pass arguments to both jest
processes by doing e.g. yarn test:unit:jest --silent
.
Builds ready [0828289]
Page Load Metrics (375 ± 17 ms)
|
Builds ready [073f7cf]
Page Load Metrics (371 ± 10 ms)
|
Co-authored-by: Mark Stacey <markjstacey@gmail.com>
892a0a1 fixes a RegEx-related bug introduced in ce15bf2, and a completely different bug discovered while trying to fix the RegEx bug. The RegEx bug was due to (what seems to me) somewhat strange behavior by the JavaScript RegEx engine (or just the spec, who knows), in that While writing tests to ensure that the parser indeed ignores sentinels preceded by non-whitespace characters (i.e. what ce15bf2 was supposed to accomplish), I discovered that the |
Builds ready [892a0a1]
Page Load Metrics (378 ± 24 ms)
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is great. Good work. Tested locally and it checks out.
@@ -0,0 +1,123 @@ | |||
# Local Browserify Transforms |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is some incredible documentation by the way. Not just this but the inline docs too.
I was expecting this transform to be difficult to understand, but it was really straightforward with all of these explanations at each step.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1000
This PR adds build-time code exclusion by means of code fencing. For details, please see the README. Note that linting of transformed files as a form of validation is added in a follow-up, #12075.
Hopefully exhaustive tests are added to ensure that the transform works according to its specification. Since these tests are Node-only, they required their own Jest config. The recommended way to work with multiple Jest configs is using the
projects
field in the Jest config, however that feature breaks coverage collection. That being the case, I had to set up two separate Jest configs. In order to get both test suites to run in parallel, Jest is now invoked via a script,./test/run-jest.sh
.By way of example, this build system feature allows us to add fences like this:
Which at build time are transformed to the following if the build type is not
beta
: