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

[jest-validate] Add config comments feature #7295

Merged
merged 11 commits into from
Oct 30, 2018
Merged

[jest-validate] Add config comments feature #7295

merged 11 commits into from
Oct 30, 2018

Conversation

andrew-pyle
Copy link
Contributor

Summary

Add feature requested in #6027. Support comments in package.json.

The NPM-sanctioned method for adding comments to package.json is via a "//" key with the comment as the value. This is done to preserve package.json as a strict JSON file. See the following:

Adds "//" to the default blacklist in packages/jest-validate/src/default_config.js.

API reference in docs/Configuration.md updated with a bit in the introduction and an entry for "//" in the Reference section.

Test plan

Unit Test

test('Comments using "//" key are not warned by default') added to __tests__/validate.test.js and passes. The test was based on the test('respects blacklist') test

Test Suites

Output of yarn run test was the same both before the changes and after, with the exception of the added unit test, which passes.

See test-suite-output.txt

Possible Issue

Passing a recursiveBlacklist array in the ValidationOptions overwrites the defaults in default_config.js and restores the warning for "//" keys.

Is this a desirable functionality, or should the "//" key be permanently included in the recursiveBlacklist array passed to the validate() function?

Copy link
Collaborator

@thymikee thymikee left a comment

Choose a reason for hiding this comment

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

LGTM

"//": "Comment goes here",
"verbose": true
}
}
Copy link
Collaborator

Choose a reason for hiding this comment

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

I don't think we need to document this, but I won't complain

Copy link
Contributor Author

Choose a reason for hiding this comment

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

So leave as is?

Copy link
Collaborator

Choose a reason for hiding this comment

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

Delete here and leave the one below

Copy link
Member

@SimenB SimenB left a comment

Choose a reason for hiding this comment

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

Great job!

Possible Issue

Passing a recursiveBlacklist array in the ValidationOptions overwrites the defaults in default_config.js and restores the warning for "//" keys.
Is this a desirable functionality, or should the "//" key be permanently included in the recursiveBlacklist array passed to the validate() function?

I think we should ensure that // is allowed even on custom blacklists

packages/jest-validate/src/__tests__/validate.test.js Outdated Show resolved Hide resolved
@SimenB
Copy link
Member

SimenB commented Oct 28, 2018

You can run yarn prettylint docs/Configuration.md --fix locally to fix the error reported by CI 🙂

@SimenB
Copy link
Member

SimenB commented Oct 28, 2018

Oh, can you add an entry to the changelog for this?

@andrew-pyle
Copy link
Contributor Author

Useful but not completely necessary question:

I am able to use the tests in __tests__ to test my code changes, but I am having trouble setting up a new project to use my development build of Jest as documented in CONTRIBUTING.md.

I'd like to manually run Jest to see my changes in action.

Would linking jest-cli with yarn be enough to use my updated jest-validate code? Or do I need to link the jest-validate code specifically? Could someone make a suggestion?

@codecov-io
Copy link

codecov-io commented Oct 29, 2018

Codecov Report

Merging #7295 into master will increase coverage by <.01%.
The diff coverage is 100%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #7295      +/-   ##
==========================================
+ Coverage   66.54%   66.54%   +<.01%     
==========================================
  Files         241      241              
  Lines        9316     9317       +1     
  Branches        6        6              
==========================================
+ Hits         6199     6200       +1     
  Misses       3114     3114              
  Partials        3        3
Impacted Files Coverage Δ
packages/jest-validate/src/validate.js 100% <100%> (ø) ⬆️
packages/jest-jasmine2/src/jasmineAsyncInstall.js
packages/jest-jasmine2/src/jasmine/createSpy.js
packages/jest-jasmine2/src/jasmine/SpyStrategy.js
packages/jest-jasmine2/src/treeProcessor.js
...ackages/jest-jasmine2/src/assertionErrorMessage.js
packages/jest-jasmine2/src/isError.js
packages/jest-jasmine2/src/jestExpect.js
packages/jest-jasmine2/src/jasmine/CallTracker.js
packages/jest-jasmine2/src/errorOnPrivate.js
... and 25 more

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 5a624d4...81c287f. Read the comment docs.

@rickhanlonii
Copy link
Member

@ndrew-pyle yeah you should be able to link as it's documented in the CONTRIBUTING.md - what are you seeing that doesn't work

Also - do we need to document this? I don't really think it's necessary to call it out since it's not a Jest thing. The few people that know about it will use it and those who don't won't need us to tell them about it

@SimenB
Copy link
Member

SimenB commented Oct 29, 2018

@andrew-pyle
Copy link
Contributor Author

andrew-pyle commented Oct 29, 2018

@rickhanlonii I'm new to Jest, so I'm attributing this to my inexperience.

Even though the tests for my changes in the jest-validate repository are passing as expected, when I run my linked Jest in a local test repo, I'm still getting the Validation warning. Same as on https://repl.it/repls/ThornyHatefulVirus. This could mean that there is still an issue with the code, but I'm not sure how to verify that my code changes are actually being used.

EDIT:

The changes seem to be effective in my test repo now. I'm not sure what changed, but I feel that the cause was indeed inexperience.

@andrew-pyle
Copy link
Contributor Author

andrew-pyle commented Oct 29, 2018

@SimenB Made change to include the default blacklist even with user-supplied blacklists in 81c287f.

  • Concatenates the recursiveBlacklist array from default_config.js with the ValidationOptions object passed as an argument
  • Uses || boolean to supply empty array if ValidationOptions doesn't have a recursiveBlacklist key.

Potential Issue
All items in the recursiveBlacklist array from default_config.js are preserved, meaning that if more elements are added in addition to "//", they will also be permanent from the user's perspective. Is this the preferred functionality?

@thymikee
Copy link
Collaborator

Should be fine :). Can you rebase/merge latest changes from master?

@SimenB SimenB merged commit fb61bff into jestjs:master Oct 30, 2018
@SimenB
Copy link
Member

SimenB commented Oct 30, 2018

Thanks @andrew-pyle!

@andrew-pyle
Copy link
Contributor Author

@thymikee @SimenB @rickhanlonii Thank you all! This has been a pleasant first contribution to an open source project!

@andrew-pyle andrew-pyle changed the title [WIP] [jest-validate] Add config comments feature [jest-validate] Add config comments feature Oct 30, 2018
@rickhanlonii
Copy link
Member

Thank you @andrew-pyle and congrats on your first Jest contribution 😃

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

6 participants