-
-
Notifications
You must be signed in to change notification settings - Fork 26.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
fix: resolve new JSX transform issues #9788
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -11,6 +11,15 @@ | |
// React App support, and is used as the `baseConfig` for `eslint-loader` | ||
// to ensure that user-provided configs don't need this boilerplate. | ||
|
||
const hasJsxRuntime = (() => { | ||
try { | ||
require.resolve('react/jsx-runtime.js'); | ||
return true; | ||
} catch (e) { | ||
return false; | ||
} | ||
})(); | ||
|
||
module.exports = { | ||
root: true, | ||
|
||
|
@@ -41,8 +50,10 @@ module.exports = { | |
}, | ||
|
||
rules: { | ||
'react/jsx-uses-react': 'warn', | ||
'react/jsx-uses-vars': 'warn', | ||
'react/react-in-jsx-scope': 'error', | ||
...(!hasJsxRuntime && { | ||
'react/jsx-uses-react': 'warn', | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. According to the blog post, it won't hurt if users still import React, however they don't need to do it if the version of React they have supports the new transform. So I think it's correct to flag There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It's also worth noting that this may mislead users who have the new transform installed, but aren't using Create React App and haven't configured Babel for the new transform. If we release the ESLint config as a major, and add that to the release notes, I think we'll be fine. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Note that opening a project to see a hundred lint warnings would be a bad experience. Especially if people don’t realize there is a codemod they can run. They will also be copy-pasting code from the web that has this import. How do we plan to explain this? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I almost think it shouldn’t warn in the transitional period. We can tighten it up later as a separate breaking change. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I had it that way - then flipped it, as I wasn't sure. We can swap that back of course. This will be a major version, so we do have the opportunity to detail these changes (and why) in the release notes - but I understand not everyone reads those. We could also look to add a custom ESLint rule for this - but that seems like overkill. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. |
||
'react/react-in-jsx-scope': 'error', | ||
}), | ||
}, | ||
}; |
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.
is anything going to break by removing the option to pass in runtime?
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.
No, that was introduced for v4 and hasn't been released yet. @iansu can confirm though.
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.
Hmm. This doesn't look right. I think it is dangerous to check right in the preset. React might not necessarily be resolvable from that path (e.g. a monorepo setup). I think it was correct to keep this an option in the preset.
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.
It also makes the preset's behavior non-deterministic depending on whether you install React before or after you first compile you code. Wrong output might get cached.
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.
#9822
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.
Hi @gaearon, we discussed the risk around resolution on the last call, but weren't sure of the right path forward. I've asked @ianschmitz and @iansu for their thoughts on the new issue you've raised too - thanks!