Stop Cloud9 IDE from giving me the warning message.
I am coding JavaScript using the Cloud9 IDE, and wherever I use a class from another file (in the same folder) I get the warning message:
VarName is not defined, please fix or add /*global VarName*/
Now this bugs me and I want to fix it.
The obvious solution would be to just add the comment /*global VarName*/
and be done with it, but I don't believe this is a good practice.
After researching, I came across the JavaScript import
functionality. In theory, this would allow me to do something like import "myOtherJsFile"
and be done with it.
This would be a good standardized solution for the problem, as many other languages take the same approach.
However, even after adding the said line, I still get the warning. It wont go away.
After creating a thread on the official forums I am now confident enough to post here what I learned.
There were discussed four ways of solving the problem:
.eslintrc
file with all the globalsimport
and export
/*global varName*/
at the top of the fileTo avoid the message one can simply turn off the "mark undefined variables" option in the project settings.
Although this solution will work, it will simply stop marking all undefined variables, even the ones you want it to mark. For this reason, I don't recommend this approach.
One can also create an .eslintrc
think file with all the globals, like the following:
{
"globals": {
"var1": true,
"var2": false
}
}
More information on configuration: http://eslint.org/docs/user-guide/configuring
The problem with this approach is that every time you create, delete or change a global variable, you have to update the global variables file.
This can quickly become cumbersome and I am not even going to discuss the maintenance impacts on big projects, which would soon become a nightmare.
The way I see it, a techy solution, but not practical.
The preferred solution, as it relies solely on JavaScript and is very similar to the import and export functionalities on other languages.
The problem with this approach however, is that at the time of writing of the answer, no browser supports either the export
nor the import
keywords:
In the future this may change, but for now it is as it is, so we cannot use this solution either.
By exclusion of parts, since solutions one and two are either prone to huge side effects or either have huge scaling problems, this is the solution I will be using for the time being.
It has no side effects, scales very well due to its independence regarding other files and most importantly, once solution 3 becomes available to use, it will be very easy to simply replace the comments with a call to the import
keyword.
For the time being, solution 4 is the best practice. However, once browsers add support for solution 3, that should be used instead of solution 4.
Special thanks to Harutyun Amirjanyan for his tenacity, patience and guidance in helping me solve this issue.