Uh oh!
There was an error while loading. Please reload this page.
added react-scripts lint - #2729
Conversation
facebook-github-bot
commented
Jul 6, 2017
Thank you for your pull request and welcome to our community. We require contributors to sign our Contributor License Agreement, and we don't seem to have you on file. In order for us to review and merge your code, please sign up at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need the corporate CLA signed. If you have received this in error or have any questions, please contact us at cla@fb.com. Thanks! |
facebook-github-bot
commented
Jul 6, 2017
Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Facebook open source project. Thanks! |
gaearon
left a comment
There was a problem hiding this comment.
See comments above.
It would also be great to add a step verifying react-scripts lint works before and after ejecting as part of "simple" end-to-end test.
There was a problem hiding this comment.
I would prefer that we use require.resolve here rather than hardcode node_modules path.
devonjs
commented
Jul 6, 2017
@gaearon updated PR (rebased) with your notes for require.resolve and simple e2e test. Found that on the close event listener, ESLint will send a code of 0 or 1 on successful finishes (0: ESLint found no lint errors, 1: ESLint found lint errors) so that code is not particularly useful. So what we can only mainly check is errors throughout and the closing signal. |
gaearon
commented
Jul 12, 2017
Apologies, what I meant is we should add |
devonjs
commented
Jul 18, 2017
@gaearon updated commit, let me know what you think |
devonjs
commented
Aug 1, 2017
@gaearon ping! |
Timer
commented
Aug 2, 2017
Hmm, I'm really not sold on the benefit here. This can be handled on CI way more accurately as I'll leave it to your discretion, @gaearon. |
devonjs
commented
Aug 18, 2017
@Timer yeah, it's a bit weird to really test if linting works or not. Putting it in Is there a better way in the |
There was a problem hiding this comment.
This should exit with an exit code. Otherwise CI wouldn't fail.
There was a problem hiding this comment.
I don't think we need to log this.
There was a problem hiding this comment.
After ejecting this should somehow let it infer config from package.json.
gaearon
commented
Aug 18, 2017
This is for the case when build is taking minutes and you just want to do a quick lint check. |
devonjs
commented
Sep 5, 2017
@gaearon updated, apologies in advance for a bit of hand-holding through this |
react-scripts-dangerous
commented
Sep 29, 2017
Hello! I'm a bot that helps facilitate testing pull requests. Your pull request (commit a452a0f) has been released on npm for testing purposes. npm i react-scripts-dangerous@1.0.11-a452a0f.0
# or
yarn add react-scripts-dangerous@1.0.11-a452a0f.0
# or
create-react-app --scripts-version=react-scripts-dangerous@1.0.11-a452a0f.0 folder/Note that the package has not been reviewed or vetted by the maintainers. Only install it at your own risk! Thanks for your contribution! |
Stupidism
commented
Oct 23, 2017
How is this going? |
RWOverdijk
commented
Oct 23, 2017
For anyone interested, I solved this differently because I have some other code styles to follow. It's really not that challenging: Create an Add a linting script in
That's it. Now you cna run |
Being able to run |
gaearon
commented
Jan 14, 2018
Agreed, we want to take this in some form. It's been a while so I don't quite remember why this PR does things in the way it does. Let me leave a comment. |
| try { | ||
| eslintConfigPath = require.resolve('eslint-config-react-app'); | ||
| } catch (e) { |
There was a problem hiding this comment.
When would this throw and why? I don't understand.
| try { | ||
| eslintConfigPath = require.resolve('eslint-config-react-app'); | ||
| } catch (e) { | ||
| eslintConfigPath = require.resolve('../../../package.json'); |
There was a problem hiding this comment.
Why would package.json count as a valid config?
| require.resolve('eslint/bin/eslint'), | ||
| '--config', | ||
| eslintConfigPath, | ||
| 'src/**/*.{js,jsx}', |
There was a problem hiding this comment.
Need to include .mjs now that we support it.
It's interesting that this doesn't filter tests out. I guess we can say it's a feature. (Currently there's no way to lint tests.)
| npm link "$root_path"/packages/react-scripts | ||
| # Test lint | ||
| "$root_path"/packages/react-scripts/bin/react-scripts.js lint |
There was a problem hiding this comment.
This doesn't make sense to me. What is this testing?
After you eject, react-scripts doesn't exist (it might on CI but you shouldn't rely on this—the point of ejecting is to wipe out react-scripts on the next installs).
So the script clearly doesn't "still work" after ejecting. If you had "lint": "react-scripts lint" before ejecting, it will stop working after.
gaearon
commented
Jan 14, 2018
@devonjs Thanks for your initial work with this! I think this PR might need somebody’s helping had to push this through. I’m sorry I didn’t get time to review it in more detail earlier. @trevordmiller If you want to pick this up given the above review and resubmit it with these points addressed we can definitely try to get it in! |
maciej-ka
commented
Jan 17, 2018
I would give a try to close this. Should I open a new PR to submit changes? |
trevordmiller
commented
Jan 17, 2018
@gaearon Thanks! Sorry, I'm currently swamped or else I would. I appreciate the invite though. @devonjs or @maciej-ka seem like they could maybe do it? |
gaearon
commented
Jan 17, 2018
@maciej-ka Sounds good! |
techrah
commented
Jan 19, 2018
Please provide link to new PR. Thanks! :) |
Added react-script for linting with specifications in #1217 & #2625