Comments (9)
Simple wrapping code into a IIFE fixes the issue, but I believe it should be "resolved" even when not wrapped.
from escope.
Thank you for your report.
Currently, we take quite conservative analysis. (This is because we use escope for minifier, it should not break the code)
Since it's a global scope, there's a lot of chance to define variables. e.g. window.variable = x
.
We cannot determine that reference is absolutely resolved with this variable declaration.
So escope makes references to the global variables as unresolved.
While the minifier requires the very conservative assumption, the other tools (such as linters) requires moderate assumptions. For such cases, escope
provides optimistic
option.
You can use it like,
scopeManager = escope.analyze(ast, { optimistic: true });
In the above case, localVar
should be found in the globalScope.references
and it should be marked as resolved
with the variable, while globalObj
reference is stored in the through
and it is noted as not resolved
.
Is it good for your use cases?
from escope.
NOTE:
If you specifies optimistic: true
, it affects on the with
and eval
scopes.
If it is preferable to handle the global scope specially, please inform me.
I'll add / extend the escope to handle it :D
from escope.
As far as I understand, window.variable
can appear inside IIFE as well, so it doesn't really help if you avoid it only in the global scope. On the other hand, those vars that are explicitly defined, have absolutely same semantics in global and function scopes, and you can be always sure that it's defined and "resolved".
Where am I wrong?
from escope.
In any case, ability to get them as resolved
through flag would be definitely sufficient for my needs, everything else is just pure interest :)
from escope.
As far as I understand, window.variable can appear inside IIFE as well, so it doesn't really help if you avoid it only in the global scope. On the other hand, those vars that are explicitly defined, have absolutely same semantics in global and function scopes, and you can be always sure that it's defined and "resolved".
Thank you! Strictly speaking, there's a difference.
If it's a function scope, basically (unless there's eval
. eval
is also treated conservatively in escope) all variables are defined in the provided code and we can know the status of the variables. (configurability)
However, the global scope is not the same. The global scope may have the other variables.
For example, we assume that our global object has testing
property with {configurable: true}
.
In this environment, the following script raises ReferenceError
.
var testing = 42;
delete testing; // We can delete this variable since it's pre-defined as `{configurable: true}`
// or delete globalObject.testing also has the same effect...
console.log(testing); // raise ReferenceError
So for the minifier, we give up the analysis on the global object now...
But I also think it's a little bit too stict ;)
I think it's useful that analyzing the explicitly defined global variables and mark them (with some property, such as explicitlyResolved
). What do you think of?
from escope.
Thanks for a detailed explanation!
But I also think it's a little bit too stict ;)
Yeah, I also think that people don't use delete
often enough to make those vars unavailable at all just for it.
I think it's useful that analyzing the explicitly defined global variables and mark them (with some property, such as explicitlyResolved). What do you think of?
This could definitely work, thanks!
from escope.
This could definitely work, thanks!
OK, so I'll implement it :)
from escope.
Thanks!
from escope.
Related Issues (20)
- Function Expression
- Error on ImportDeclaration HOT 1
- Update scope manager scopes once it was created HOT 2
- Add support for label scoping
- New escope-demo (not a bug)
- Add node.body check before attempting to vist children HOT 8
- Variables from global scope have empty references array
- Drop `es6-map`. HOT 1
- Function scope arguments variable HOT 1
- Drop using require'd assert in favour of just throwing an error
- Enter the version directly in index.js
- Problem with unused library functions
- let declaration treated as var declaration HOT 1
- Can't locate variable within named function's scope when function assigned to other variable HOT 4
- Function declarations attached to block scope? HOT 1
- Another version of escope HOT 1
- what does 'through' in escope mean? HOT 1
- Maybe i find a bug in escope ?
- Is ES6 parameter scope not supported? HOT 1
- JSDoc unavailable: 404 error
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from escope.