I finally got to the point where my javascript code compiles in the google closure compiler without any errors or warnings. Now I want to recompile the code generated and when I paste that code back into the compiler, I get over 100 warnings: most of them are JSC_REDECLARED_VARIABLE and a few JSC_INEXISTENT_PROPERTY.
Why is that?
I do not think the Google Closure Compiler produces code that is intended for further compilation.
To have code compile correctly you have to keep some structure. But that extra structure is among the things removed by the compiler and without it the compiler cannot correctly interpret the code.
You should be able to do the easier modes of compilation but not the advanced one.
REDECLARED_VARIABLE is a WARNING not an error. It is intended to indicate a likely problem to the developer. A developer might ignore this if they know what they are doing and the compiler does.
Related
I use the normal error logging in the console...
Following the call stack trace and all. Never had much of a problem.
A friend recommended ESLint. After looking at some screenshots, I don't see much of a difference between what ESLint does and normal error logging.
Could anyone please compare the two, perhaps giving pro's and con's.
Bonus Points: include some use-cases in which one would be better than the other.
ESLint:
ESLint is a linter -a tool that analyzes your code and flags potential errors. This is very helpful to avoid common mistakes that are made while you're coding (using undefined variables, syntactic errors, etc).
Pros:
Helps preventing syntactic mistakes
Helps preventing common errors
Helps you adhere to coding conventions
...
Cons:
Need to setup
It can get a bit annoying sometimes...
Browser Console:
On the other side, the console is a tool that you can find in all modern browsers. As opposed to a linter, in the console you'll find runtime errors -ie. errors occurred during the execution of your code.
ESLint vs Console:
You don't have to choose between one or the other. Both cover different needs and both can help you deliver better software.
If you're coding Front-End JavaScript, I'm sure you already use your browser console on a daily basis.
On top of that, you can choose to use a linter or not.
A linting tool helps me avoid silly mistakes when writing JavaScript. Despite my many years of experience, I still type variable names incorrectly, make syntax errors and forget to handle my errors properly. A good linting tool, or a linter, will tell me about this before I waste my time—or worse, my client’s time. A good linting tool can also help make sure a project adheres to a coding standard.
There are many linters available for JavaScript like JSLint, JSHint, JSCS and ESLint, Let’s take a look at at pros and cons of alternatives:
Pros
avoid silly mistakes when writing JavaScript
avoid making syntax errors
adheres to a coding standard
Comes configured and ready to go (if you agree with the rules it
enforces)
Best ES6 support, and also the only tool to support JSX
Resolve error before compiling with good IDE plugin for linting
etc..
Cons
You can’t add custom rules (not for all cases)
Difficult to know which rule is causing which error
Some configuration required
Slow, but not a hindrance
Examples:
Strict type checking in conditions:
you will get lint error for no strict type checking in below code.
`a == b && foo == null`
with lint error you can resolve to this to avoid
`a === b && foo === null`
variable not defined
you will get lint error for no variable declared in below code.
'foo' is assigned a value but never used. and 'bar' is not defined.
var foo = bar;
What compiler options are best to ensure that dartdevc generates minifier friendly javascript code which can be compressed by google closure compiler in ADVANCED mode.
Please show a tested example that specifies options for 1. dartdevc, and 2. java -jar goolge-closure-compiler.jar as a simple bash script, without pub.
Module type should be 'common' if possible, dart_sdk.js should be included, the final result should be es3 or es5 for compatibility with all browsers, and all output goes into one compressed .js file.
The dartdevc compiler is not meant for production usage at this time, and does not support any sort of "advanced" optimizations (such as those done by the Google Closure Compiler). Our only supported optimization path is using dart2js, our optimizing compiler which in many cases is as good as or better the Google Closure Compiler.
See "When should I use dartdevc" on our FAQ page:
Use dartdevc whenever you’re actively working on your code.
Keep using dart2js to build your deployed, production application. With dart2js you get advanced optimizations such as tree shaking to minimize downloaded code size.
I'm excited you'd like to see dartdevc work for more use cases, but we are concentrating on a great developer experience and keeping optimization usage in dart2js at this time.
Should I use JSLint on my CoffeeScript project when I'm already running CoffeeLint on all the files? I don't think this question is subjective. Here would be objective reasons not to:
Does CoffeeLint already run JSLint? If yes, that would make JSLint redundant
Does CoffeeScript generate code that will make JSLint fail in ways that I have no control over? If yes, JSLint will just get in my way
Does CoffeeScript automatically generate code that is JSLinted? That would make running JSLint a waste of time.
No, there is no benefit to running JSLint against JavaScript produced from CoffeeScript.
The output of CoffeeScript's compilation isn't under your control, and it isn't meant to pass any form of linting, so there is absolutely no value to running JSLint against it. You can't fix any problems you find, and there will be a lot of problems.
Linters are for catching human-induced errors in source code, not for finding bugs in transcompilers like CoffeeScript's.
Does CoffeeLint already run JSLint? If yes, that would make JSLint redundant
No
Does CoffeeScript generate code that will make JSLint fail in ways that I have no control over? If yes, JSLint will just get in my way
This, exactly
Does CoffeeScript automatically generate code that is JSLinted? That would make running JSLint a waste of time.
No
I recently noticed and fixed a pretty bad JS bug in our software, affecting all IE versions, that was caused by a simple mistake in a .js file:
const foo = "..."
Now, IE doesn't support const; it's a syntax error. var should be used instead. (The offending keyword was actually inserted unwittingly by IntelliJ IDEA's "introduce variable... -> introduce constant" refactoring.)
Our automated Selenium tests are run with Firefox on Linux, and getting them running on IE would probably be too much hassle right now.
Anyway, my question is, is there any static JS code analysis tool that
would have caught the const bug (and similar common problems), and
can be easily triggered from a CI tool (Jenkins) against certain .js files in a codebase?
I am aware of JSHint, JSLint and Google Closure Tools, but I don't know if any of them meets my criteria above.
JSHint or JSLint would have caught the error in time. You can configure IntelliJ to show these kind of issues realtime. There is a Jenkins plugin available as well. I hope you find those useful. :)
I've been tinkering with Google's Closure Compiler and was able to get everything compiling perfectly using the advanced compilation option. How can I get the best compilation results from my code?
Read about Advanced compilation.