Allow package.json files to be piped into the builder to support typeVersions #81
Conversation
|
cc: @jrieken, @weswigham |
rbuckton
force-pushed
the
supportTypesVersions
branch
2 times, most recently
from
2aa12bb to
e43092e
Compare
|
We should be considering this before the 3.6 TS release so vscode can actually be built, right? |
|
There are no changes to TypeScript needed to support this. This issue lies solely in |
rbuckton
force-pushed
the
supportTypesVersions
branch
from
e43092e to
610e902
Compare
| @@ -195,6 +195,12 @@ export module maps { | |||
| map.remove = multiMapRemove; | |||
| return map; | |||
| } | |||
| export function createUniqueMultiMap<T>(): MultiMap<T> { | |||
There was a problem hiding this comment.
Is this function being used?
| function getDirectories(path: string): string[] { | ||
| return !noFileSystemLookup && ts.sys.getDirectories(path); | ||
| function addTrailingDirectorySeparator(file: string) { | ||
| return file && file.charAt(file.length - 1) !== '/' ? file + '/' : file; |
There was a problem hiding this comment.
Do we need to use path.sep for these checks so that it works properly cross platform?
|
Sorry, but VS Code isn't using gulp-tsb@master but gulp-tsb@2.0.x. That means we won't benefit from any of the changes here. Can someone explain to me what this effort is all about? It seems that I missed something. Can VS Code not be compiled with TS 3.6 without these or other changes? Is just the Generally, we want to get out of gulp-tsb and use the tsc as-is. We only have gulp-tsb because |
|
The approach we've taken in the TypeScript repo is to just call Our build just queues up parallel requests to build projects and passes them all at once to a single |
Given that we only have one project, is the |
|
Follow-up question on https://www.typescriptlang.org/docs/handbook/project-references.html#caveats. Does that apply to syntax errors only or also to semantic errors? |
|
If you don't have multiple projects, |
|
Given that
Let's take a step back. Is enabling file system lookup and disabling piping of |
Essentially, yes. |
|
Great. I pushed a few changes to gulp-tsb and published it as 4.0.0 - gulp-tsb is now allowed to read files (we see how that affects perf) and things compile with postinstall-deletion-hacks. Closing PR |
This PR fixes an issue that is currently blocking microsoft/vscode#77835.
In TypeScript 3.1 we added support for a compiler version compatibility feature known as "typesVersions". When the compiler attempts to resolve an import or type reference directive we now look for a
"typesVersions"field in the referenced import'spackage.jsonfile. This field indicates path redirections based on the version of the running TypeScript compiler.Unfortunately, when
gulp-tsbis run withnoFilesystemLookupenabled, the compiler is unable to look up thepackage.jsonfile. This is further exacerbated in the case of microsoft/vscode#77835, as vscode includesnode_modules/@types/**/*.d.tsin the set of files piped togulp-tsb, resulting in colliding declarations due to the inclusion of both@types/node/index.d.tsand@types/node/ts3.2/index.d.ts.I've made the following changes to address these issues:
rootNamesto be provided to TypeScript, any non .ts/.tsx (or .js/.jsx in the case ofallowJS) file is removed. This allowspackage.jsonfiles to be piped into agulp-tsbbuilder so that they can be discovered whennoFilesystemLookupis enabled."typesVersions"whennoFilesystemLookupis enabled, thegetDirectoriesmethod ofHostis implemented to emulate a directory list using the file list known to the host.excludeNodeModulesFromRootNamesoption to prevent cases such as when bothnode_modules/@types/node/index.d.tsandnode_modules/@types/node/ts3.2/index.d.tsare included in therootNames(which would effectively ignore the setting for"typesVersions"as they are explicitly provided).createWithIConfigurationfunction export that allows you to specify theexcludeNodeModulesFromRootNamesoption along with a path to atsconfig.jsonfile so as not to clutter the defaultcreatefunction export.