| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
With one or two additional comments
Still need to 1. Make it work in Typescript. 2. Add test (and make them work) for the other uses of GlobalThis: window, globalThis, etc.
Lots of tests still fail, but all but 1 change so far has been correct.
A couple of tests still fail and need to be fixed.
The type reference must be `typeof globalThis`. Just `globalThis` will be treated as a value reference in type position -- an error.
I left the noImplicitThis rule for captured use of global this in an arrow function, even though technically it isn't `any` any more -- it's typeof globalThis. However, you should still use some other method to access globals inside an arrow, because captured-global-this is super confusing there.
I ran into a problem with intersecting `Window & typeof globalThis`: 1. This adds a new index signature to Window, which is probably not desired. In fact, with noImplicitAny, it's not desired on globalThis either I think. 2. Adding this type requires editing TSJS-lib-generator, not this repo. So I added the test cases and will probably update them later, when those two problems are fixed.
I decided I didn't like the import-type-based approach. Update baselines to reflect the difference.
(typeof globalThis)["globalThis"] should work fine, right? |
Sorry, something went wrong.
I assume this is specifically about sloppy mode code, right? In strict mode, or in modules, the global this should be undefined, not any or globalThis. |
Sorry, something went wrong.
|
From later discussion, I noticed that window.x = 12, at least at top-level in a script, should result in binding a global variable 'x'. |
Sorry, something went wrong.
|
@Kovensky you are right but that would probably be a big breaking change. It'll be easier to test in a separate PR, so I will do it that way. It would be a good idea to ship that change in the same version as this one, though. |
Sorry, something went wrong.
globalThis is no longer constructed lazily. Its synthetic Identifier node is also now more realistic.
| //// function f(this) { return this; } | ||
|
|
||
| verify.singleReferenceGroup("this"); | ||
| verify.singleReferenceGroup("module globalThis\nthis: typeof globalThis"); |
There was a problem hiding this comment.
Hm. We might want a custom way to display the symbol associated with the global scope. Like just (global) globalThis?
Sorry, something went wrong.
There was a problem hiding this comment.
I don't like the current state, but isn't there some value to printing typeof globalThis ? It teaches people what type they have to write to refer to the type of globalThis.
Sorry, something went wrong.
There was a problem hiding this comment.
eh? I don't really feel too strongly about it. It just felt like for something as core as a reference to the global scope, something a little more clear then module globalThis; this: typeof globalThis may be warranted. It's a unique object and so maybe deserves unique output.
Sorry, something went wrong.
There was a problem hiding this comment.
I didn't expect, and don't like, module globalThis. I'll figure out why it appears.
On the other hand, globalThis is a unique object, but one whose binding acts like any other global variable, so it weirds me out a little to say that this should display as globalThis at top-level. I kind of like saying that this has the type typeof globalThis instead.
Let's discuss at the design meeting. I could go either way.
Sorry, something went wrong.
|
I just ran the user tests and nothing failed there. That's a good sign. |
Sorry, something went wrong.
|
Notes from Design meeting:
|
Sorry, something went wrong.
In progress, had to interrupt for other work.
|
Is this the same as what global::: can solve in C#? That is, the outerWobbler variable in namespace PluginA can now be defined of type IWobbler with the help of globalThis below? namespace Data {
export namespace Components {
export interface IWobbler {
wobble(): void;
}
}
}
////IN SOME OTHER FILE
namespace PluginA {
var outerWobbler: globalThis.Data.Components.IWobbler = undefined;
//this namespace breaks outerWobbler since you can't reference Data.Components.IWobbler
export namespace Data {
//other stuff for PluginA's Data
}
}
Workaround at the moment is something like ////IN SOME OTHER FILE - HACKY WORKAROUND
type AliasForIWobbler = Data.Components.IWobbler;
namespace PluginB {
var outerWobbler: AliasForIWobbler = undefined;
export namespace Data {
//other stuff for PluginB's Data
}
}
|
Sorry, something went wrong.
|
Ian Yates (@IanYates) This is already available as global on node and this or window (sort of mostly) in the browser. globalThis is just a standard name for it. This PR adds a type for the global namespace so you get that instead of any. That is, the example you posted works today if you substitute global for globalThis, except you don't get completions. After this PR, you will. |
Sorry, something went wrong.
|
All right, I think this is ready to go. Wesley Wigham (@weswigham) Mind taking another look? |
Sorry, something went wrong.
1. Add parameter to tryGetThisTypeAt to exclude globalThis. 2. Use combined Module flag instead combining them in-place. 3. SymbolDisplay doesn't print 'module globalThis' for this expressions anymore.
| if (outsideThis) { | ||
| addRelatedInfo(diag, createDiagnosticForNode(container, Diagnostics.An_outer_value_of_this_is_shadowed_by_this_container)); | ||
| const type = tryGetThisTypeAt(node, /*includeGlobalThis*/ true, container); | ||
| if (noImplicitThis) { |
There was a problem hiding this comment.
Rather than switching on noImplicitThis out here, shouldn't we use errorOrSuggestion (switching on noImplicitThis) instead of error so we get suggestions for these issues even when noImplicitThis is off?
Sorry, something went wrong.
There was a problem hiding this comment.
Suggestions are only used for triggering codefixes, I think. And there aren't any codefixes for these errors. If both of these are true, then let's just wait until we have a codefix for them.
And I can't think of a good codefix for any of the errors except perhaps "The containing arrow function captures the global value of this", which would convert the arrow function to a function expression.
Sorry, something went wrong.
| return anyType; | ||
| } | ||
| if (leftType.symbol === globalThisSymbol) { | ||
| if (noImplicitAny) { |
There was a problem hiding this comment.
Same here, but for noImplicitAny.
Sorry, something went wrong.
|
Apparently the current implementation only works when variables are defined in a global file. Currently, I'm using window as follows (like everyone apparently!). How can this be achieved with globalThis? declare global {
interface Window {
MyAppStores: {
FileStore: FileStoreI;
}
}
}
...
window.MyAppStore = { FileStore } |
Sorry, something went wrong.
dperetti you can try this interface AppStore {
FileStore: FileStoreI;
}
declare global {
var MyAppStores: AppStore;
}Both window and globalThis will recognize the type for that variable. For typing globalThis you should use var not let or const |
Sorry, something went wrong.
|
It doesn't seem there is a good way to extend globalThis using an interface. interface globalThis extends Window {}The above keeps failing with:
I'm on typescript version 4.1. Also I was expecting that extending Window will propagate the properties to globalThis, but it doesn't: interface RuntimeGlobals {}
interface Window extends RuntimeGlobals {} |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
globalThis now has a name and has advanced to stage 3, so this PR adds it to Typescript. It's based on #22891, which we delayed until the proposal had come up with a name.
This change injects a global namespace symbol globalThis whose exports is the global symbol table. This enables much better checking.
If you need to refer to the global type, use typeof globalThis.
Open items:
Notes: