Validate JavaScript code without enforcing a specific style

Question

I would like to validate some JavaScript code for syntactic correctness, but without enforcing a specific coding-style to the user.

My first approach was to use esvalidate that comes included with esprima. This does the job partially, as it detects unexpected tokens, such as:

constx foo = {};

What it does not detect is among other things usage of variables that have never been declared, such as:

const foox = {
  bar() {}
};

foo.bar();

A tool such as eslint would detect this, but it's very difficult to configure ESLint in a way that no specific style is enforced to the user (I don't say it's not possible, I just say it's a huge amount of work since you need to check every single rule and decide whether to enable or disable it, and with hundreds of rules this is… yes, well, a huge amount of work).

What other options do I have? How could I validate the code without this effort?

By the way: What is it that I want to validate here? It's not the syntax (I mean, syntactically, everything is fine, it just does not make sense), but it's also not the semantics. What would be the correct term for this type of checks?

There's also [jshint](http://jshint.com/). At least both jshint and eslint are highly configurable. — David Gomes, Jul 31 '16 at 06:34
That's true, but basically I have the the same problem here (okay, there a way less rules in JSHint than in ESLint). But, maybe using a linter is the completely wrong approach? Please note that I am not looking for a specific tool, I'd rather be interested in how you call what I like to do so I can search the web myself. (Okay, tbh, if somebody comes up with a tool which does exactly what I need, I won't say "no" ;-)) — Golo Roden, Jul 31 '16 at 06:36
Validators like eslint work by enforcing rules. You can either go with something very strict (standard), somewhat strict (xo) or a custom set of not so strict rules. You can also transpile code with babel and it will throw on invalid code. — Pier-Luc Gendreau, Jul 31 '16 at 06:36
I got your point, but… I'd expect that there is a difference between a rule that defines where to put spaces and rules that ensure… yes, what? I mean, using a variable that was not declared is not about *style*, it's also not about *syntax*, it's about ... what? "Correctness"? — Golo Roden, Jul 31 '16 at 06:37
As mentioned in your second example, almost anything is valid JavaScript, this is where you need a linter to have a look at the code for *style* which in reality is more than just *style*. I suggest you check out [ESLint's Possible errors](http://eslint.org/docs/rules/#possible-errors) rules. — Pier-Luc Gendreau, Jul 31 '16 at 06:47
Your suggestion of "correctness" sounds appropriate for the concept you are describing. — nnnnnn, Jul 31 '16 at 07:37

score 1 · Accepted Answer · answered Jul 31 '16 at 15:35

Years ago Linters were only there to check the style of your code. Nowadays they do more, a lot more. Even static analysis. ESLint is such a powerful tool and IMHO it is exactly what you're looking for.

You may think the initial configuration may be costly, but as the ESLint page says:

No rules are enabled by default.

Besides, having a consistent coding style across your time is very beneficial and if you and your team found a common basline you can share the .eslintrc between projects.

Enabling the no-undef rule and using a plugin for your IDE, like one of those should solve your issue -> static code analysis at development time :)

score 0 · Answer 2 · answered Jul 31 '16 at 06:37

0

To answer your last question, I think that what you want is static analysis. This will be harder with JavaScript in general because of its dynamic nature and lack of types, and relative lack of maturity in tooling. Decades of work have gone into writing static analyzers for C, for example, and that work won't immediately carry over into others languages.

Something like jshint may be what you want because its goal is to help developers "write complex programs without worrying about typos and language gotchas".

Hope this helps!

answered Jul 31 '16 at 06:37

Joshua Gross

526
6
10

I think that's not 100% accurate. Flow, TypeScript and also ESLint show that it is possible to have really good static analysis in JavaScript. – Sebastian Sebald Jul 31 '16 at 15:16
Flow and Typescript are languages that transpile to Javascript; you can transpile/compile Haskell to Javascript, but that doesn't make Javascript a strongly-typed language. There is some great tooling for Javascript but static analyzers are very immature compared to static analyzers for languages that are decades older. – Joshua Gross Aug 01 '16 at 22:34
Flow doesn't transpile JS, TS does. But usind TypeScript's language service while developing will give you a static analyzer. And of course are static analyzers that exist much longer also more mature. Also not what I said. I only wanted to point out, that it is possible to do helpful/good static analysis in JavaScript. – Sebastian Sebald Aug 02 '16 at 07:01

score 0 · Answer 3 · answered Aug 04 '16 at 14:38

ESLint Recommended set: Recommended rules have checkmark next to them do not include any stylistic rules. You can use that to verify validity of the script without enforcing any specific style. At the very least it's a good starting point, and you can always turn off the rules you don't like.

Validate JavaScript code without enforcing a specific style

3 Answers3