Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 422715

Summary:	[eslint] erroneous "variable is not defined" warnings from ESLint
Product:	[ECD] Orion	Reporter:	Manu Sridharan <m.sridharan>
Component:	JS Tools	Assignee:	Mark Macdonald <mamacdon>
Status:	RESOLVED FIXED	QA Contact:
Severity:	normal
Priority:	P3	CC:	mamacdon
Version:	unspecified
Target Milestone:	5.0 M1
Hardware:	PC
OS:	Mac OS X
Whiteboard:

Description Manu Sridharan

2013-11-27 16:37:28 EST

I just pulled from master (commit ca26d3e947738a0f00cf719728765ea0031d0da6) and loaded the following file in Esprima:

https://github.com/SRA-SiliconValley/jalangi/blob/master/src/js/analysis.js

Now I see many erroneous warnings about undefined variables.  E.g., on line 29 I see a warning:

'MODE_RECORD' is not defined

But, line 29 is declaring the variable MODE_RECORD.  I tried the command-line eslint installed from npm and didn't see these warnings; I'm guessing it might be an issue with the custom rules Orion is using.

I cleared my browser cache and ran localStorage.clear() in Chrome and still see these issues; hopefully it's reproducible.

Is there some way to run eslint with Orion's custom rules from the command line?  If so, I can try to find a smaller input that reproduces the behavior.

Comment 1 Mark Macdonald

2013-11-27 17:39:13 EST

Thanks Manu, I can reproduce this too. 

The problematic rule is 'no-undef', which is used in both ESLint master and Orion, but our drop of ESLint is several months behind master, so this bug may've been fixed upstream there. Might also be a bug in escope (one of ESLint's dependencies), as we're using an old version of that as well. Anyway, I'll have a look.

> Is there some way to run eslint with Orion's custom rules from the command 
> line?  If so, I can try to find a smaller input that reproduces the behavior.

Yes: in the Orion client repo, cd to bundles/org.eclipse.orion.client.javascript/web/eslint/ and run
> npm install
To grab the dependencies. 

The tests are in tests/lib/rules/ -- to run them just do
> mocha tests/lib/rules
or for a single file:
> mocha tests/lib/rules/no-undef.js

Comment 2 Manu Sridharan

2013-11-27 18:10:14 EST

Cool, here's a much smaller input that shows the problem, minimized from the previous one:

(function() {
    var MODE_RECORD = 1;
    function callAsNativeConstructorWithEval() {
        return eval();
    }
})();

Comment 3 Mark Macdonald

2013-11-27 21:12:24 EST

Thanks! It looks like this issue in escope: https://github.com/Constellation/escope/issues/27

The fix is to use the 'optimistic' option, but... that doesn't exist in escope v0.0.14, which is what we have approved. I will try opening another CQ to pick up a newer release.

Comment 4 Manu Sridharan

2013-11-29 10:46:10 EST

It looks like in eslint, they passed an 'ignoreEval' option to escope to address the related bug:

https://github.com/nzakas/eslint/commit/736d0eed4ccfbd886673ba551412f92904db8e5e

But it looks like the ignoreEval option isn't in the version of escope currently packaged with Orion either...oh well.

Comment 5 Mark Macdonald

2013-11-29 10:56:56 EST

Yes, I think ignoreEval was the original name for 'optimistic' in older versions of escope. https://github.com/Constellation/escope/pull/18#issuecomment-20326035

I'm hoping to just move up to escope 1.0.0 and refactor no-undef to take advantage of the new globalScope.implicit data structure that they now provide.

Comment 6 Mark Macdonald

2013-12-03 12:26:52 EST

Updated eslint and escope, so this should be fixed now.
\