| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
| else if (arg.arguments.types) { | ||
| typeReferenceDirectives.push({ pos: arg.arguments.types.pos, end: arg.arguments.types.end, fileName: arg.arguments.types.value }); | ||
| } | ||
| else if (arg.arguments.lib) { |
There was a problem hiding this comment.
#23904 Could avoid repeated code here
Sorry, something went wrong.
There was a problem hiding this comment.
Do you want me to do this or do you want to do in your other PR once this is merged?
Sorry, something went wrong.
There was a problem hiding this comment.
I'll close the other PR since it doesn't have much benefit with only 2 branches, but maybe it would have a benefit with 3 branches, or there's a better way to share the code.
Sorry, something went wrong.
| >Array.from : { <T>(arrayLike: ArrayLike<T>): T[]; <T, U>(arrayLike: ArrayLike<T>, mapfn: (v: T, k: number) => U, thisArg?: any): U[]; <T>(iterable: Iterable<T> | ArrayLike<T>): T[]; <T, U>(iterable: Iterable<T> | ArrayLike<T>, mapfn: (v: T, k: number) => U, thisArg?: any): U[]; } | ||
| >Array : ArrayConstructor | ||
| >from : { <T>(iterable: Iterable<T> | ArrayLike<T>): T[]; <T, U>(iterable: Iterable<T> | ArrayLike<T>, mapfn: (v: T, k: number) => U, thisArg?: any): U[]; <T>(arrayLike: ArrayLike<T>): T[]; <T, U>(arrayLike: ArrayLike<T>, mapfn: (v: T, k: number) => U, thisArg?: any): U[]; } | ||
| >from : { <T>(arrayLike: ArrayLike<T>): T[]; <T, U>(arrayLike: ArrayLike<T>, mapfn: (v: T, k: number) => U, thisArg?: any): U[]; <T>(iterable: Iterable<T> | ArrayLike<T>): T[]; <T, U>(iterable: Iterable<T> | ArrayLike<T>, mapfn: (v: T, k: number) => U, thisArg?: any): U[]; } |
There was a problem hiding this comment.
Shouldn't arrayFrom.ts have a Set test? Then if would break due to this change since Set is Iterable but not ArrayLike.
Sorry, something went wrong.
There was a problem hiding this comment.
I'll add a test, but this shouldn't break because there is still an overload that supports Iterable. The order just changed because I cleaned up the default order of libs. Previously if you had a "lib": ["es5", "es2015"] in your tsconfig.json we would actually end up inserting them in reverse order because we were doing files.unshift for default libs.
Sorry, something went wrong.
There was a problem hiding this comment.
Was this intentional?
Sorry, something went wrong.
There was a problem hiding this comment.
Not sure what caused that to change, but I'll revert.
Sorry, something went wrong.
| // Internally we add some additional lib references that we only support when used as part of a | ||
| // "lib" reference directive. They are not available on the command line or in tsconfig.json. | ||
| /* @internal */ | ||
| export const libMap = cloneMap(commandLineLibMap) |
There was a problem hiding this comment.
i would just add this to the map. chances are no one will ever include it.. and if they did.. it does not break anything.
Sorry, something went wrong.
| @@ -0,0 +1,14 @@ | |||
| /// <reference lib="es5" /> | |||
There was a problem hiding this comment.
should not this just be:
/// <reference lib="es2015" />
/// <reference lib="dom" />
/// <reference lib="dom.iterable" />
/// <reference lib="webworker.importscripts" />
/// <reference lib="scripthost" />
Sorry, something went wrong.
| /// <reference lib="dom" /> | ||
| /// <reference lib="webworker.importscripts" /> | ||
| /// <reference lib="scripthost" /> | ||
| /// <reference lib="dom.iterable" /> No newline at end of file |
There was a problem hiding this comment.
nit. i would move this just after dom
Sorry, something went wrong.
| @@ -1,3 +1,5 @@ | |||
| /// <reference lib="webworker.importscripts" /> | |||
There was a problem hiding this comment.
this is not needed here, the file is autogenerated, and it already has the correct definition. we add it to lib.d.ts to partially allow the lib to be used in webworkers for simple cases..
the two files dom and webworker have too many conflicts in between them, and can not be loaded together in the same context anyways..
so I would just revert the changes to this file, and leave it as is.
Sorry, something went wrong.
| "es5.full": "lib.d.ts", | ||
| "es2015.full": "lib.es6.d.ts" | ||
| }, | ||
| "sources": { |
There was a problem hiding this comment.
can we remove the support for sources from jake and gulp as well.
Sorry, something went wrong.
| /* @internal */ | ||
| export const compileOnSaveCommandLineOption: CommandLineOption = { name: "compileOnSave", type: "boolean" }; | ||
|
|
||
| // NOTE: The order here is important to default lib ordering |
There was a problem hiding this comment.
i would expand on this comment and say that the order of the list here is the same order the lib files have in the generated program, and add a note to see use in createProgram
Sorry, something went wrong.
| } | ||
|
|
||
| export function getReferenceAtPosition(sourceFile: SourceFile, position: number, program: Program): { fileName: string, file: SourceFile } | undefined { | ||
| debugger; |
There was a problem hiding this comment.
remove
Sorry, something went wrong.
There was a problem hiding this comment.
one debugger statement that needs to be removed
Sorry, something went wrong.
|
Great job with this PR! The diff won't load for me so I'll just ask here 🤔 ... Does this PR actually implement <reference lib> in such a way to make the TS engine smaller? Or is this PR just implementing the feature itself and the usage will be implemented in a different PR? For more context see: #23339 (comment) Thanks! 👍 |
Sorry, something went wrong.
|
lib folder should go down by 4 MB or so. |
Sorry, something went wrong.
|
Mohamed Hegazy (@mhegazy) Ron Buckton (@rbuckton) This is going to be a big break to API consumers loading just lib.d.ts from the TS and expecting things to work - what's the mitigation here for APIs loading e.g. a fixed set of files from the network on load? |
Sorry, something went wrong.
|
You could always just use an older copy of the lib, if you're one of those API consumers. We ship the latest one with the latest features for consumers, but if you have constraints that force you to, usually you can just include an older copy of the lib in your project - a bunch of our older RWC tests do that. |
Sorry, something went wrong.
|
If we get feedback on that we can ship an all in one file as well. The biggest issue is tool authors really, like TS-loader for instance. Most users use the built in lib with no changes. |
Sorry, something went wrong.
|
Will it add the library to the entire program or only from the reference point and downward? |
Sorry, something went wrong.
|
not sure i understand the question. the only difference is instead of on file lib.d.ts you will have a set of them in your program. |
Sorry, something went wrong.
|
Ron Buckton (@rbuckton) Mohamed Hegazy (@mhegazy) this has broken our own build because buildProtocol builds up its program with --noResolve. Checking out fbeb58a and running jake LKG twice fails. Now noResolve effectively means you don't load any standard library types at all, which will be visible to more than just API consumers. |
Sorry, something went wrong.
|
Looks like we need to ignore noResolve when we are resolving lib files as well.. we already have a ignoreNoDefaultLib flag, so we can extend this to mean resolvingLibReference and ignore noResolve as well as noDefaultLib |
Sorry, something went wrong.
|
--disableIgnoreSkipNoResolve |
Sorry, something went wrong.
|
I'll take a look. Lib refs are supposed to ignore noResolve. |
Sorry, something went wrong.
|
This had nothing to do with noResolve and more to do with buildProtocol.ts looking only ignoring "lib.d.ts". It also looks like its already fixed in master. |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
This change adds support for a /// <reference lib="name" /> directive, allowing a file to explicitly include an existing built-in lib file.
In the long term this can help polyfill/shim packages like core-js or es6-shim.
NOTE: Apparently we were very close to running out of heap memory when running gulp tests after running gulp clean as gulp is holding onto too much memory. Individually each task is fine, but in concert they add up to a large amount of uncollected memory. To address this, I've added a script to run some of our builds out-of-process. This is not an issue in the jake builds.
Fixes #15732.
Supersedes #15780