Getting JSX syntax to play nicely with jslint?

[TYRONEMICHAEL]

I have been playing around with the library. I am trying to use their JSX syntax, and was just wondering how you guys get it to play nicely with jslint/jshint?

JSLint obviously does not like the JSX syntax - ("expected an identifier and instead saw ' <';" - JavaScript syntax error), so how do I get around this in my .jshintrc file?

[jordwalke]

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?

[petehunt]

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.

[TYRONEMICHAEL]

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.

[petehunt]

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

[TYRONEMICHAEL]

Would definitely be something I am interested in as I definitely prefer the JSX syntax - much easier to visualize in code.

[danielmiladinov]

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.

[sophiebits]

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.

[danielmiladinov]

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

[sophiebits]

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.

[jeffmo]

I wonder if you could hack your jshint plugin to run jsx first before passing off to jshint? #dogscience...

[danielmiladinov]

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. :)

[jordwalke]

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

[petehunt]

Do you think jshint would be receptive to a syntax transform patch?

[jordwalke]

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