JSHint Next with Esprima

[Anton Kovalyov]

Hey,

We're at the point where we need to start working on integrating a new parser so I decided to make an executive decision and pick one. I've decided that it makes sense to go with Esprima (http://esprima.org/). We should try to use it without modifying Esprima too much. We should also attempt to push modifications we make upstream.

Before I create a branch and start hacking a few points to discuss:

• Yay or nay: tabs instead of spaces (I converted Hiro.js and a couple of other projects to tabs and it feels much better)?
• Yay or nay: new codes for messages: W<int>, E<int>. Example: PEP8.
• Yay or nay: pub sub system for lint-hooks (i.e. for people to hook into the parsing process to make their own rules).
• Anything else you want to discuss this week.
  

Anton

[Josh Perez]

Great news.

Nay on tabs. Big fan of spaces. I'm not too religious about this
however, just voicing my opinion.
Yay for new codes for warnings/errors. This means we can translate the
errors into other languages or even change the wording in the future
yet keep the same code for consistency and this will work on all tools
that rely on JSHint
Yay for lint hooks. Flexibility is great.

Josh

[Anton Kovalyov]

Reasoning for spaces/against tabs? Just curious.

Anton

[Josh Perez]

- Maintains code consistency and feels like all code was written to 1
person. All code is indented X amount of spaces everywhere. Web,
diffs, code, GitHub, etc.

- The css property tab-size isn't implemented on all browsers yet so
code will looks bad on the web when it's tabs. Plus most editors
convert tabs to spaces which makes it annoying to copy/paste from web
to editor and vice versa.

Overall, I am not too concerned about how many columns code is
indented. I am more concerned with having code be consistent.

On the plus side for tabs, files are smaller.

[Leo Balter]

It's a lot easier to keep a consistent code with only spaces indentation than tabs. Same way you'll know how others will look your code indentation with spaces, tabs change a lot in viewers/browsers/editors, etc

Nay on tabs, yay on others.

2012/1/25 Josh Perez <goats...@gmail.com>

[Wolfgang Kluge]

I'm busy the next days (and the last weeks *g*). So in short

I can't imagine how to change a strict parser to ignore most of the errors (e.g. something like "var i j;" or invalid strings/regex) without braking everything - but let's try it ;)

tabs or spaces: most of my time as developer I used tabs. The last two years I switched to spaces (more and more). The reason was that there are so many developers out there that use spaces, that I have to change my editors settings all the time (it's not really better due to indentation level and different formating options). I don't care - as long as it's consistent. The only thing I really don't like is the mix of spaces and tabs (jsdoc)

new codes: "yan" (*g*), I think we should access the warnings/errors more naturally ("messages.white.exceptedWhitespace"). Also, a rule should not be responsible if a specific message is outputted as warning, as error, or maybe not at all (ignored) - it has just to detect it (and return it / put it into an array / ..).

hooks: yay - also for the internal rules

More

• yay or nay: break code into several parts (needs make/jake to create a working file)
• yay or nay: new option-system. I think we need more precise options

Wolfgang

[Anton Kovalyov]

Thanks for feedback, guys.

FWIW, I've been doing some Go programming in my spare time and their standard is tabs only, enforced by a neat tool called gofmt. Not only I haven't noticed any inconsistency in style it was the opposite: code, no matter who wrote it and what editor preferences they had, always look the same.

In addition, tabs are more appealing to me on a fundamental level—4 spaces (and actually I'm a fan of 2 spaces) is not a tab while tab symbol is. This eliminates problems of editing the code in shitty editors (and sometimes you have to, when fixing bug in WSH on a VM) that don't understand that backspace should remove a tab-width (4 spaces) instead of a single space.

Another question I wanted to ask: I am thinking about using ES5 features. This means JSHint will no longer work in older environments but since we're not a general purpose library I think it's okay. Yay/nay?

Anton

[Anton Kovalyov]

Yay for breaking code into several parts. Every time I see a file with 6k lines in it I want to punch a puppy in the face. I'm working on a very simple prototype to illustrate/start discussion about some design decisions. We'll work on pushing it to the next branch during the weekend and then we can go from there.

Yay for new option system and for separating linter from code that ignores/display warnings and errors.

Anton

[Leo Balter]

yay for es5 features, jshint is a dev tool, no need to run on any browser

2012/1/26 Anton Kovalyov <antonk...@gmail.com>

[Josh Perez]

I still think JSHint should just barf on SyntaxErrors.
(https://github.com/jshint/jshint/issues/420#issuecomment-3491508)

My reasoning is that syntax errors will not work in production
regardless and jshint should be out to catch the tricky stuff that you
feel may work but doesn't really work. Besides, SyntaxErrors are easy,
the person just goes and fixes the bug and runs hint again.

I see no value in continuing to parse and guessing what the developer
intended thus raising many false positives (specially if the syntax
error occurs early on) and thus possibly breaking any tools that rely
on JSHint (I'm biased here, of course)

The only argument I see for running through regardless of Errors is
that you won't have to potentially run JSHint multiple times on that
same file if you're hinting a file that has tons of SyntaxErrors.

Yay for ES5.
Yay for modules as long as we provide an easy to download bundled jshint.js
Indifferent about the new option system (as I know nothing about this)

Yay for progress! :)

[Anton Kovalyov]

I agree with barfing on SyntaxErrors. Teaser:
http://cl.ly/0H041c2H1Q0U0u2t3q0h

Anton

[Wolfgang Kluge]

Hmm..

your only mentioned benefit (don't have to run jshint mutliple times) is *the* benefit ;)

IMO: for such tools (machine readable) there should exist an option (break on first error). But for humans, the false positives are ok and only one error is rarely enough (e.g. whitespace warnings could be there till the very end of the file).

Seems like I'm outvoted ;)

Good night - it was a long day

Yay for ES5 (dev tools can break - and modern browsers will run it, too)

Yay for easy way to provide jshint.js after modularization - maybe a git hook (build jshint, run all tests, add jshint.js to commit - on pre-commit)

[Anton Kovalyov]

We can make it more intelligent after the fact—i.e. modify Esprima to
provide more information on SyntaxError and then extract a chunk we can
parse. For example:

This code will fail with "unexpected token" on line 3:

var a = "Hello";
console.log(a)
var b=,

If we modify Esprima to return the last valid token—we can re-parse the
file up until line 3. Then, after displaying, all warnings we will end
the output with "Syntax error: can't parse further". So for our example
the output will be:

Line 2: Missing semicolon
Line 3: Unexpected token , (fatal)

Sounds like a good compromise between failing completely without and
guessing around syntax errors.

Anton

P. S. Keep your arguments coming even if you're outvoted.

[Wolfgang Kluge]

Hi,

playing with esprima a bit and found a little bug (null literals aren't different to string "null", except the raw- and the range-properties).

Looks very nice and robust (still converting coveraje from uglifyjs to esprima - there, the parser has not to be modified and I hope I can learn something about esprima and its benefits/drawbacks).

I'm trying to get whitespace information into the ast - but first I want to have an update. Where are we now? Is esprima still the first choice or are there any things that makes us impossible to use esprima?

Wolfgang

[Anton Kovalyov]

I'm pushing hard to finish my book these days but I played with Esprima and so far I have on idea: what if split JSHint into two parts: linter and styler. The former will check for things that break code (e.g. missing semicolon followed by an open paren on a new line) while the latter will check for style things (e.g. missing semicolons in all other places, (function {}()) vs. (function {})(), tabs vs. spaces, etc.). This way we can make the styler highly extendible while still preserving the integrity of JSHint as a static code analyzer.

Also, I really want to move from talking part to writing code part and that's why I'm trying to finish my book and move it out of the way as quickly as possible (one chapter left!)

Anton

P. S. You guys are doing a great job dealing with issues while I'm concentrating on other projects! Thank you so much!

[Wolfgang Kluge]

... oh, of course, jshint is currently not parsable by esprima. This is due to line 680, where "hasOwnProperty" is used as property name... I've reported the issue.

[Domenic Denicola]

As a spectator to this discussion, Esprima sounds very immature. Why do you guys like it over something more mature like Uglify?

---

From: jsh...@googlegroups.com [jsh...@googlegroups.com] on behalf of Wolfgang Kluge [didg...@googlemail.com]
Sent: Thursday, February 23, 2012 16:11
To: jsh...@googlegroups.com
Subject: Re: JSHint Next with Esprima

[Anton Kovalyov]

Mostly, lack of documentation for parse-js.js (parser used by UglifyJS).

Anton

[Josh Perez]

I don't value maturity as much as I value code quality and esprima is
very well written with good documentation and it is in active
development by Ariya.

Anton, +1 for splitting between lint and styles.

[Wolfgang Kluge]

+1 (or more) for splitting

[Wolfgang Kluge]

And Ariya is very, very fast in fixing errors... (jshint can be parsed now)

[Kaleb Hornsby]

Anton: I was browsing the jshint repo and noticed that at one point there were references to Esprima, and now there no longer are. Did jshint drop using Esprima? And if so, why?

The reason why I ask, is that I am working on a large JavaScript project, and I am trying to speed up the development tasks.

We are using a linter (jshint), doc generator, and mangler/minifier. All three of these tools generate an AST. So I was experimenting with speeding this up by generating one AST and passing that to all three of these tools.

[Anton Kovalyov]

The Esprima experiment didn't work for two main reasons:

 

 1. We didn't want to wait for Esprima to implement ES6 features. JSHint currently is the only linter that supports most stable ES6 features.

 2. We need an incremental parser: i.e. something that is able to parse unfinished code. Since JSHint is used in editors a lot we want it to be able to generate warnings for code like 'function name() { some(); if (some) {' even if you didn't finish typing it yet.

 

In future, if conditions change I'm happy to re-think this.

 

Anton

--

You received this message because you are subscribed to the Google Groups "JSHint" group.

To unsubscribe from this group and stop receiving emails from it, send an email to jshint+un...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.