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

Check watch plugins for key conflicts #6697

Merged

Conversation

tdd
Copy link
Contributor

@tdd tdd commented Jul 15, 2018

Summary

Watch plugins now are checked for key conflicts…

  • Some built-in keys remain overridable (specificically t and p).
  • Any key registered by a third-party watch plugin cannot be overridden by one listed later in the plugins list config.

Fixes #6693.
Refs #6473.

Test plan

Additional tests are provided that check every conflict / overwritable scenario discussed.

Request for feedback / “spec” evolution

The “spec” is an ongoing discussion in #6693 — in particular, the overwritability of some built-in keys, such as a, f and o, may be subject to discussion. This PR tracks the decisions in there and may evolve a bit still.

Ping @SimenB @thymikee @rogeliog for review and discussion.

const RESERVED_KEY_PLUGINS = new Map([
[
UpdateSnapshotsPlugin,
{forbiddenOverwriteMessage: 'updating snapshots ballpark', key: 'u'},
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note to reviewers: we specify the keys here because the snapshot built-in plugins only return usage info when the current running context makes them relevant, and this detection is based on internal, “private” field cooking. We don't want to interfere with / mock / hack that.

@codecov-io
Copy link

codecov-io commented Jul 15, 2018

Codecov Report

Merging #6697 into master will increase coverage by 0.1%.
The diff coverage is 96.77%.

Impacted file tree graph

@@            Coverage Diff            @@
##           master    #6697     +/-   ##
=========================================
+ Coverage   63.55%   63.66%   +0.1%     
=========================================
  Files         235      235             
  Lines        9030     9059     +29     
  Branches        3        3             
=========================================
+ Hits         5739     5767     +28     
- Misses       3290     3291      +1     
  Partials        1        1
Impacted Files Coverage Δ
packages/jest-cli/src/watch.js 81.97% <96.77%> (+2.95%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 0591f22...24cf0dc. Read the comment docs.

@SimenB SimenB requested a review from rogeliog July 16, 2018 12:30
@tdd tdd force-pushed the feat/watch-plugin-key-conflicts branch from 20cfedc to 4efebe8 Compare July 17, 2018 14:39
@tdd
Copy link
Contributor Author

tdd commented Jul 17, 2018

I just force-pushed an updated branch on top of latest master, to fix conflicts w/o butchering the graph with a reverse merge (as GitHub's UI would do). As I was force-pushing anyway, I fused both commits (original and lint:md:ci fix) as I'm not on in this for the contributors hall of fame anyway 😉

@SimenB
Copy link
Member

SimenB commented Jul 18, 2018

We squash on merge anyways 🙂

@rogeliog would you be able to take a look at this?

@SimenB
Copy link
Member

SimenB commented Jul 18, 2018

I think this deserves some docs as well, mind updating https://github.com/facebook/jest/edit/master/docs/WatchPlugins.md?

@tdd tdd force-pushed the feat/watch-plugin-key-conflicts branch from 4efebe8 to 08124bb Compare July 18, 2018 08:59
@tdd
Copy link
Contributor Author

tdd commented Jul 18, 2018

@SimenB sure thing, here goes. I took the opportunity to rebase on top of the latest master, too.

@tdd
Copy link
Contributor Author

tdd commented Jul 18, 2018

@SimenB unrelated: what's the Jest site release process like? I thought this would be automated, but it lags behind a bit most of the time (right now it's stuck on 23.3 for instance).

@SimenB
Copy link
Member

SimenB commented Jul 18, 2018

See https://jestjs.io/docs/en/next/getting-started.html.

We cut new versions when the doc warrants it. None of the changes in 23.4 had doc changes

@tdd
Copy link
Contributor Author

tdd commented Jul 18, 2018

Ah, OK. 23.4.1 had (the broader updatable options set), but as it's very recent and a patchlevel, that probably explains why it's not there yet.

@tdd
Copy link
Contributor Author

tdd commented Jul 18, 2018

(also weird: the next version fails on watch-plugins?!)

const RESERVED_KEY_PLUGINS = new Map([
[
UpdateSnapshotsPlugin,
{forbiddenOverwriteMessage: 'updating snapshots ballpark', key: 'u'},
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we change this to just updating snapshots instead of update snapshots ballpark?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Trimmed.

continue;
}
const {forbiddenOverwriteMessage} = reservedInfo;
watchPluginKeys.set(key, {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given that the key is gotten from getUsageInfo(...) , a plugin can update their designated key at any time. This is not a documented(or common) use case, so I think if we don't worry about it in this PR.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indeed. There is no formal way to obtain a list of all possible keys claimed by a plugin, so we have to trust first invocation. Context-based key changes are expected to be rather rare, though (although snapshot updates are a prime example, for instance), so let's not focus too much on that now.

- `p` (test filename pattern)
- `t` (test name pattern)

Any key not used by built-in functionality remains fair game, as you would expect. Try to avoid using keys that are difficult to obtain on various keyboards (e.g. `é`, `€`), or not visible by default (e.g. many Mac keyboards do not have visual hints for characters such as `|`, `\`, `[`, etc.)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: Don't worry about changing it, but....I'm not sure how remains fair game sounds for docs purposes

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point. I wax colloquial sometimes, losing sight of how it can make reading a bit harder for non-native English speakers. Tweaked it.

@tdd tdd force-pushed the feat/watch-plugin-key-conflicts branch from 08124bb to 703fd05 Compare July 18, 2018 22:02
@tdd
Copy link
Contributor Author

tdd commented Jul 18, 2018

I just pushed a rebased history on top of the latest master that addresses @rogeliog's good wording points.

@tdd
Copy link
Contributor Author

tdd commented Jul 18, 2018

Dammit, it looks like Netlify's deploy or some underlying API (OpenCollective?) is acting funky again 😒

Copy link
Contributor

@rogeliog rogeliog left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Awesome!

@tdd
Copy link
Contributor Author

tdd commented Jul 19, 2018 via email

@rogeliog
Copy link
Contributor

I'm not sure how to retrigger the Netlify check. I guess you could amend your last commit and re-push 😕?

@tdd
Copy link
Contributor Author

tdd commented Jul 20, 2018

@rogeliog @SimenB Netlify check fails fast still. The message is extremely unclear:

9:34:08 AM: Failing build: Failed to prepare repo
9:34:08 AM: failed during stage 'preparing repo': exit status 1

If anyone on the build infra team could look at it…

@endiliey
Copy link
Contributor

Hi, I've re-triggered the netlify preview. There is a build cache error causing it to fail.

@tdd
Copy link
Contributor Author

tdd commented Jul 22, 2018

@endiliey thanks!

Dang it, this time it's a Yarn registry timeout that failed test-jest-circus. As for the CHANGELOG conflict, I'll rebase and force push, we'll see how CI goes.

@tdd tdd force-pushed the feat/watch-plugin-key-conflicts branch from 9a7dc9a to cc69070 Compare July 22, 2018 09:29
@tdd
Copy link
Contributor Author

tdd commented Jul 22, 2018

@endiliey @rogeliog @SimenB success! all checks pass now! Ready to merge 😉

error = `Jest configuration error: watch plugins ${plugins} both attempted to register key <${key}>. Please change the key configuration for one of the conflicting plugins to avoid overlap.`;
}
console.error('\n\n' + chalk.red(error));
exit(64); // EX_USAGE
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if it makes more sense to just throw a ValidationError like we do for other configuration errors.

E.g.

{
	"jest": {
	  "collectCoverage": "wat"
	}
}

image

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@SimenB this is an interesting idea. Am I correct in assuming the right place for this would be in jest-config’s normalize.js file, in its existing handling of the watchPlugins option?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(I'm not entirely sure we'd have sufficient/relevant info to populate the arguments to the plugin's getUsageInfo() there, I'll check. At the very least we can check inline key configs, though.)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, in normalize seems natural, imo. Not sure if we have enough information there, but if not we can just hard-code the reserved ones

@tdd tdd force-pushed the feat/watch-plugin-key-conflicts branch from cc69070 to 00567a8 Compare July 26, 2018 13:25
@tdd
Copy link
Contributor Author

tdd commented Jul 26, 2018

@SimenB it turned out that moving that into jest-config's codebase wasn't practical, nor was it very clean IMHO:

  • It brought watch-specific concerns into the general config package
  • It occurred way ahead of the curve, before watch plugins can be instantiated (no global config yet, it requires normalization first)

I ended up keeping my conflict-checking code in its current location, but moved from manual console error logging and custom exit code to regular ValidationError throwing, trying to use error styling that matches existing validation errors. This works quite well in my tests.

@@ -364,6 +364,139 @@ describe('Watch mode flows', () => {
expect(run).toHaveBeenCalled();
});

describe('when dealing with potential watch plugin key conflicts', () => {

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This line causes lint failure on CI

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Dang, should have checked. Just a sec.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yarn lint --fix should solve your problem 👍

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's odd, I guess my VS Code was overwhelmed with some extension, not to have auto-run Prettier on this.

@thymikee thymikee changed the base branch from master to process-exit August 8, 2018 20:04
@thymikee thymikee changed the base branch from process-exit to master August 8, 2018 20:04
tdd and others added 6 commits August 8, 2018 22:06
@thymikee thymikee force-pushed the feat/watch-plugin-key-conflicts branch from 621e84e to 24cf0dc Compare August 8, 2018 20:09
@github-actions
Copy link

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Please note this issue tracker is not a help forum. We recommend using StackOverflow or our discord channel for questions.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators May 12, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Improve DX for watch plugin key conflicts
7 participants