References to the explicitly declared variables in the global scope should be resolved as explicitlyResolved about escope

[RReverser]

Simple wrapping code into a IIFE fixes the issue, but I believe it should be "resolved" even when not wrapped.

[Constellation]

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?

[Constellation]

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

[RReverser]

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?

[RReverser]

In any case, ability to get them as resolved through flag would be definitely sufficient for my needs, everything else is just pure interest :)

[Constellation]

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?

[RReverser]

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!

[Constellation]

This could definitely work, thanks!

OK, so I'll implement it :)

[RReverser]

Thanks!