-
-
Notifications
You must be signed in to change notification settings - Fork 30
Bug: eslint-scope
fails to create new Scope for block element
#110
Bug: eslint-scope
fails to create new Scope for block element
#110
Comments
eslint-scope
dails to create new Scope for block elementeslint-scope
fails to create new Scope for block element
https://github.com/eslint/eslint-scope/blob/main/tests/es6-block-scope.js According to these tests eslint-scope does the correct thing? |
Looks like you are getting the default ES5 scoping. Did you pass the |
Oo.. let me try that.. this could definitely be a PEBKAC issue. This is what I was using in my test REPL (Ref): const ast = espree.parse(jsCode, {
ecmaVersion: 2020,
sourceType: 'module',
range: true
});
// Analyze the scopes in the AST
const scopeManager = eslintScope.analyze(ast); Which was based off the usage example in the README: I didn't notice any links to docs pages/similar suggesting that the Beyond what's written here, are there any more details about the options? Eg. what does /**
..snip..
* @param {Object} providedOptions Options that tailor the scope analysis
* @param {boolean} [providedOptions.optimistic=false] the optimistic flag
* @param {boolean} [providedOptions.directive=false] the directive flag
* @param {boolean} [providedOptions.ignoreEval=false] whether to check 'eval()' calls
* @param {boolean} [providedOptions.nodejsScope=false] whether the whole
* script is executed under node.js environment. When enabled, escope adds
* a function scope immediately following the global scope.
* @param {boolean} [providedOptions.impliedStrict=false] implied strict mode
* (if ecmaVersion >= 5).
* @param {string} [providedOptions.sourceType='script'] the source type of the script. one of 'script', 'module', and 'commonjs'
* @param {number} [providedOptions.ecmaVersion=5] which ECMAScript version is considered
* @param {Object} [providedOptions.childVisitorKeys=null] Additional known visitor keys. See [esrecurse](https://github.com/estools/esrecurse)'s the `childVisitorKeys` option.
* @param {string} [providedOptions.fallback='iteration'] A kind of the fallback in order to encounter with unknown node. See [esrecurse](https://github.com/estools/esrecurse)'s the `fallback` option.
..snip I stumbled onto this It might be useful to update the README with a little more info/links about the With my old REPL test code, the output was:
After correctly setting it to parse with $ node espree-eslint-scope_2.js
-= SCOPE INFO =-
Scope: type=global (block.type=Program) block.id?.name=undefined implicit=x,console,console,x
Variable: x [ { type: 'Variable', kind: 'const' } ] References: 2
-= SCOPE INFO =-
Scope: type=block (block.type=BlockStatement) block.id?.name=undefined implicit=undefined
Variable: x [ { type: 'Variable', kind: 'const' } ] References: 2 After setting it to parse with $ node espree-eslint-scope_2.js
-= SCOPE INFO =-
Scope: type=global (block.type=Program) block.id?.name=undefined implicit=console,console
-= SCOPE INFO =-
Scope: type=module (block.type=Program) block.id?.name=undefined implicit=undefined
Variable: x [ { type: 'Variable', kind: 'const' } ] References: 2
-= SCOPE INFO =-
Scope: type=block (block.type=BlockStatement) block.id?.name=undefined implicit=undefined
Variable: x [ { type: 'Variable', kind: 'const' } ] References: 2 So it seems it's not a bug after all, and just user error on my part. Better docs in the README would definitely help avoid cases like this in future though too. |
Yeah, we just kind of lazily forked |
Background Context
While exploring a variable renaming issue (pionxzh/wakaru#32) there was a reference to some example code that failed in another parser when block statements were involved (facebook/jscodeshift#263)
In trying this out with
eslint-scope
(pionxzh/wakaru#32 (comment)), it seems that the bug also may exist here.Description
I've encountered an issue with
eslint-scope
where it does not seem to create a new scope for a block element in JavaScript code. According to ECMAScript specifications,let
andconst
declarations within a block{ ... }
should have block-level scope. However,eslint-scope
seems to be treating the block as if it doesn't create a new scope.Code to Reproduce
Here is a simple code snippet that illustrates the issue:
In this code, there are two separate scopes: the global scope and the block scope. The variable
x
is declared twice, once in each scope. According to JavaScript scoping rules, these should be treated as two different variables.Expected Behavior
eslint-scope
should recognize and create a new scope for the block element, treating the innerconst x = 47;
as a separate variable scoped within the block.Actual Behavior
Currently,
eslint-scope
does not seem to differentiate between the two scopes in the provided code snippet. It treats the entire code as if it's in a single scope, which is not consistent with standard JavaScript scoping rules.Additional Information
eslint-scope
version:7.2.2
18.12.1
The text was updated successfully, but these errors were encountered: