-
Notifications
You must be signed in to change notification settings - Fork 12.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Design Meeting Notes, 12/10/2021 #47151
Comments
PR up for correlated union types is up #47109 |
Hello! I'm the developer behind esbuild. I noticed that you're running the TypeScript compiler through esbuild, so I couldn't help trying it out myself. I've been meaning to do cross-module enum inlining so I did a quick implementation and tried it out on the branch in #46567. Here's a simple benchmark of the result:
These tests measure the time to type check the Rollup code base (with fixes for type errors due to the TypeScript upgrade). As you can see, bundling with esbuild after inlining enums results in a TypeScript compiler build that's the same speed as the one in But I had to fix a bug in that branch that was slowing things down a lot (the "fixes" columns in the table): diff --git a/src/compiler/corePublic.ts b/src/compiler/corePublic.ts
index 11c5416b54..4334edad7f 100644
--- a/src/compiler/corePublic.ts
+++ b/src/compiler/corePublic.ts
@@ -138,6 +138,7 @@ namespace NativeCollections {
export function tryGetNativeMap(): MapConstructor | undefined {
// Internet Explorer's Map doesn't support iteration, so don't use it.
// eslint-disable-next-line no-in-operator
+ const Map = globalThis.Map as any;
return typeof Map !== "undefined" && "entries" in Map.prototype && new Map([[0, 0]]).size === 1 ? Map : undefined;
}
@@ -147,6 +148,7 @@ namespace NativeCollections {
export function tryGetNativeSet(): SetConstructor | undefined {
// Internet Explorer's Set doesn't support iteration, so don't use it.
// eslint-disable-next-line no-in-operator
+ const Set = globalThis.Set as any;
return typeof Set !== "undefined" && "entries" in Set.prototype && new Set([0]).size === 1 ? Set : undefined;
}
} This code was picking up on the local versions of Anyway just wanted to share this result and bug fix. It's totally up to you whether or not you use esbuild, so no pressure. I imagine there are concerns about wanting to dogfood the TypeScript compiler. I was actually surprised to see you trying out esbuild at all. Edit: Oh yeah, also I shipped cross-module enum inlining in esbuild version 0.14.7 if you want to try it out. |
@evanw you're a life-saver. @elibarzilay can you experiment with the above? The only catch is that we don't always have const localGlobal =
typeof globalThis !== "undefined" ? globalThis :
typeof global !== "undefined" ? global :
typeof window !== "undefined" ? window;
const Map = localGlobal.Map as any; |
I think one other thing to consider is that this is something the conversion script kept working, but silently wrong. Seems like nested namespaces and places where we use local |
@evanw Thanks for that and sorry that I got to it so late. I'm guessing that you were running esbuild directly on the TS sources--? I'm using it with the CJS output of the compiler, and that has some differences in runtime -- specifically, my concern was the time it takes to run the full set of TS tests... First, I didn't see any change when bumping the version (which is probably expected, given that it's the cjs output). Second, the Map/Set bug didn't actually affect the cjs output since it doesn't create a global but uses |
Yes, that's correct. I did that because you need to run esbuild on the TS sources to take advantage of TS features such as enum inlining, so that's the fastest way to run the code. |
RE: #38511
Can you explain this with an example please? I don't fully understand how importing self can achieve the same thing as proposed.
Apparently export implements { default: number };
export default 1 |
In theory you can write import * as self from "./self.js"
const _: ExpectedType = self; |
"Correlated Union Types"
#30581
We want to be able to feed the callback with the original value; but now
v
is a union type andf
's parameter type is an intersection; that's not precise forv
, and that intersection now only acceptsnever
.People have speculated that maybe we need existential types so that we can say "this function takes whatever type
v
has" and can feed it through.Can try to re-model this in the form of a re-indexed mapped type.
With some improvements of inference and apparent types, we can enable most of these cases - 2 improvements on the scale of what feel like bug fixes.
{ [P in K]: Foo<P> }[X] => Foo<X>
This is a weird pattern. Would like to not have to teach people to write this.
Modules Migration Status Update
#46567
__createBindings
issue.Ensuring Modules Conform to a Type
#38511
export implements SomeType
thatThe text was updated successfully, but these errors were encountered: