Comments (20)
I recently put in a pull request to jshint that adds a feature to ignore a block of lines in javascript and resume linting afterward. I specifically had JSX in mind.
You could enclose your JSX within the jshint comment directives
/*jshint ignore:start */
and
/*jshint ignore:end */
and the rest of your code should lint as normal. If you're defining react components in the file that only get used inside a JSX block, we typically add the line
void MyReactComponent;
Near the JSX block to assuage the unused variable warnings.
I'd appreciate your thoughts and/or feedback on this.
from react.
fYou must first pass the source code through the JSX transform. Once that is done, everything should work perfectly. One benefit to how we've proceeded with JSX, is that we preserve line numbers in the transforms so using lint (once transformed) will "just work".
That means that jslint will even catch:
var p = <Typeahead />
If Typeahead
is not a variable in scope! (It will complain that Typeahead
is not defined.) I have a customized version of a vim jslint plugin that highlights lint errors with a red underline. I'm just working on getting Windows support. Would something like that work for you? What's your lint flow?
from react.
You can do this with jsx --watch. The in-place transform may benefit you as well; the tool supports a --extension directive such that you can transform .jsx files to .js files alongside each other.
from react.
Thanks so much for the quick and detailed response. Actually running Sublime with Sublime Linter, so obviously it tries to lint the JSX syntax and thus keeps throwing errors. Might have to take your customization of the VIM plugin and try create something similar for SublimeLinter. I think it is quite easy to extend. But for the meantime, I think I will just run jslint on build after it has run through the JSX transform and turn it off while in dev. It's just nice to have it run in the background catching silly errors while developing. Thanks again for the hardwork! Find it as a powerful alternative to Views in Backbone.
from react.
No problem @TYRONEMICHAEL . I was experimenting with the idea of forking jshint to build jsxhint; if this is something you're interested in please let me know (not saying I can get it done anytime soon, but can try to get it on the roadmap at least.)
from react.
Would definitely be something I am interested in as I definitely prefer the JSX syntax - much easier to visualize in code.
from react.
As you can see in the earlier comments, it's recommended to just run jshint after doing the JSX transform. I implemented this for the Khan Academy linting tools this weekend, so if you download https://github.com/Khan/khan-linter and do runlint.py file.jsx
, then everything should Just Work. (Not really designed for external use, but useful if you're looking for something to copy.) Maybe I'll make a jsxhint npm package that calls jsx then jshint in turn.
from react.
@spicyj, I understand the recommendation, and that's fine for doing something like running jshint as part of a CI build step or what have you.
My particular flow is that I use IntelliJ/Webstorm's JSHint plugin to automatically highlight linter errors before I've even checked my code in, let alone kicked off a build. I have found it very handy to have that immediate feedback. Since switching to react, my only regret was seeing the linter barf on the first line of JSX in my javascript files.
Having to comment out my JSX to see if the rest of my code lints was enough of a drag that it motivated me to work on this patch.
from react.
Gotcha. Maybe it makes sense for someone to write a JSXHint plugin. :) I have my vim configuration set up to use khan-linter; there's no reason I know of that IntelliJ can't do the same.
from react.
I wonder if you could hack your jshint plugin to run jsx first before passing off to jshint? #dogscience...
from react.
It's not my plugin, it's built into intellij/webstorm/phpstorm.
Not a separate plugin, but actually integrated into the javascript editor.
In the settings here's nothing to tweak on it except a version drop-down, which apparently just reads package.json from the jshint site, and you can specify a path to your .jshintrc file, if you have one.
Edit:
So, the sooner my patch gets accepted and a new version released, the sooner I can start using my new feature right inside my IDE. :)
from react.
@danielmiladinov: How do they handle things like coffeescript linting? I'd really seriously recommend doing it right, and not avoiding certain regions. The reason is that you're actually missing some seriously awesome linting action by ignoring regions.
<Typeahead
userName={"user:" + theUserName}
/>
Is just sugar for
Typeahead({
userName:"user:" + theUserName
});
In my Vim linter, it tells me if Typeahead
is not defined, or if I've mispelled theUserName
or if theUserName
variable is not in scope etc. Are there any webstorm linting plugins that you could fork? I'm sure people around here would help you integrate jsx
+ jshint
into it.
from react.
Do you think jshint would be receptive to a syntax transform patch?
from react.
@petehunt: It's hard to tell. JS+JSX is a superset of JavaScript, and syntactically compliant with E4X, which is another variant of JS - the trouble is that JSHint would need to assume the particular transformation that we apply (simple function calls) in order to extract value from the linting process. Then again, would anyone want to transform JSX into anything other than function calls (or something congruent with respect to linting)? Likely not.
from react.
For those who missed it, https://github.com/Enome/jshintreact may help, at least in the short term.
from react.
Another version from @toddself https://github.com/CondeNast/JSXHint
from react.
@jordwalke, sorry for my so-late reply, the JSHint plugin we use doesn't have too many options, other than setting a non-standard location for your .jshintrc file, and choosing which version of the main jshint repository you want to run.
That's why I was hoping for my pull request to make it into jshint proper, so that I could leverage it right in my IDE, to get that immediate feedback before having to run a build.
Failing that, I may reach out to JetBrains themselves and see what we can do to perhaps open up more options, say, something "use this build of jshint please, and thank you very much" and point it at a directory or something like that. Then anybody could use whatever custom features in their own jshint installs they needed the most.
from react.
@danielmiladinov as far as I understand it, the better approach for jetBrains would be to have a plugin specifically targetting jsx syntax. Since their ide allows the use of "language injections".
see feature request: http://youtrack.jetbrains.com/issue/WI-21217
from react.
@CircleCode, I agree, that would be an awesome feature! However, it's orthogonal to the question of linting in general, and their JSHint plugin in particular.
All their JSHint plugin does is "shell out", (not to make too much light of it; I'm so grateful for it) to whatever version of JSHint you've downloaded (it's configurable in the options), and puts the relevant error messages with red squigglies on the relevant line numbers in your editor. (You see what the error was when you mouse over the squigglies, very handy)
Their editor is already pretty good at inferring that you're using some kind of xml literal right in the middle of your javascript. It doesn't understand the notion of "valid-for-jsx" xml, but it already goes a long way to ensuring your jsx is at least well-formed xml: that is, unless you put your jsx expression inside parentheses, with a single root tag, and every starting tag is either self-closing or has a corresponding close tag, the rest of your javascript syntax coloring just goes completely crazy, indicating that you're doing something very wrong ;)
All it's missing is the convention of valid jsx, i.e., that tag names correspond either to "global" React.DOM components or your own custom components (which must then be visible in the current scope) and that attribute names correspond to component prop names and that attribute values correspond to expressions containing variables from the current scope. But I'm beginning to describe how the JSX Transform works, aren't I?
from react.
I was actually hoping for something that would actually lint the raw JSX as part of the coding process. The jsx compiler obviously catches almost everything with specific line numbers and then it's easy to fix the typos after a compile attempt, but it sucks that you have to run the compiler to find syntax errors that a static analysis would reveal.
Simply ignoring sections of code doesn't fix the problem of static analysis.
Is there any formal definition of JSX syntax (like a language report) anywhere that could be used as a guide for a true static parser/linter?
As to linting after the JSX transform, I'm with the crowd that doesn't care whether the compiled by machine code of any altJS conforms to some arbitrary standard of best style.
from react.
Related Issues (20)
- [React 19] Export SuspenseException HOT 2
- [React 19] [bug] SVG with dangerouslySetInnerHTML content does not trigger first click HOT 8
- [React 19] - `ReactElement` created from `React.createElement` are not renderable anymore HOT 3
- [Compiler Bug]: function parameter inside component override outer parameter incorrectly
- forceUpdate not work in child component GuardGraph
- [React 19] useOptimistic is not updating its optimistic collection immediately HOT 6
- Bug: useEffect and Event Handler Timing Regressions in React 18 Legacy Mode HOT 1
- [DevTools Bug]: No way to debug suspense events
- [Compiler Bug]: setState in useEffect / react compiler and eslint hooks plugin HOT 1
- [DevTools Bug] Cannot add node "20468" because a node with that id is already in the Store. HOT 1
- [Help Wanted] How can I become a member of reactjs? HOT 1
- [React 19]useEffect cleaned the wrong state in StrictMode HOT 7
- Inability to prioritise hydration & react yields too willingly HOT 2
- [DevTools Bug]: Script tag connection method not working in 6.0.0 HOT 1
- Bug: DevTools 6.0.0 element inspector not working with React Native 0.75 HOT 1
- Bug: re-rendering order of onBlur and onClick inconsistent between desktop and mobile browsers HOT 2
- React 19 Beta: Component Suspense Not Fallbacking as Expected HOT 1
- [DevTools Bug] Cannot destructure property 'duration' of 'e[g]' as it is undefined. HOT 1
- Bug: Performance Degradation in Concurrent Mode with Suspense and Nested Lazy Components
- Bug: circular import between shared/ReactSharedInternals.js and react/src/React.js HOT 10
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from react.