-
-
Notifications
You must be signed in to change notification settings - Fork 6.5k
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
[jest-validate] Add config comments feature #7295
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.
LGTM
docs/Configuration.md
Outdated
"//": "Comment goes here", | ||
"verbose": 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.
I don't think we need to document this, but I won't complain
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.
So leave as is?
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.
Delete here and leave the one below
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.
Great job!
Possible Issue
Passing a
recursiveBlacklist
array in theValidationOptions
overwrites the defaults indefault_config.js
and restores the warning for"//"
keys.
Is this a desirable functionality, or should the"//"
key be permanently included in therecursiveBlacklist
array passed to thevalidate()
function?
I think we should ensure that //
is allowed even on custom blacklists
You can run |
Oh, can you add an entry to the changelog for this? |
Useful but not completely necessary question: I am able to use the tests in I'd like to manually run Jest to see my changes in action. Would linking |
@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 |
Might make sense to document in https://github.com/facebook/jest/blob/master/packages/jest-validate/README.md |
@rickhanlonii I'm new to Jest, so I'm attributing this to my inexperience. Even though the tests for my changes in the 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. |
- Supplies empty array when user-supplied ValidationOptions has no recursiveBlacklist key.
@SimenB Made change to include the default blacklist even with user-supplied blacklists in 81c287f.
Potential Issue |
Should be fine :). Can you rebase/merge latest changes from master? |
Thanks @andrew-pyle! |
@thymikee @SimenB @rickhanlonii Thank you all! This has been a pleasant first contribution to an open source project! |
Thank you @andrew-pyle and congrats on your first Jest contribution 😃 |
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. |
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 preservepackage.json
as a strict JSON file. See the following:package.json
Adds
"//"
to the default blacklist inpackages/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 thetest('respects blacklist')
testTest 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 theValidationOptions
overwrites the defaults indefault_config.js
and restores the warning for"//"
keys.Is this a desirable functionality, or should the
"//"
key be permanently included in therecursiveBlacklist
array passed to thevalidate()
function?