-
Notifications
You must be signed in to change notification settings - Fork 12.5k
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
Unhandled error when computing local module specifier #37731
Labels
Working as Intended
The behavior described is the intended behavior; this is not a bug
Milestone
Comments
devversion
added a commit
to devversion/angular
that referenced
this issue
Apr 1, 2020
In rare cases a project with configured `rootDirs` that has imports to non-existent identifiers could fail in the migration. This happens because based on the application code, the migration could end up trying to resolve the `ts.Symbol` of such non-existent identifiers. This isn't a problem usually, but due to a upstream bug in the TypeScript compiler, a runtime error is thrown. This is because TypeScript is unable to compute a relative path from the originating source file to the imported source file which _should_ provide the non-existent identifier. An issue for this has been reported upstream: microsoft/TypeScript#37731. The issue only surfaces since our migrations don't provide an absolute base path that is used for resolving the root directories. To fix this, we ensure that we never use relative paths when parsing tsconfig files. More details can be found in the TS issue. Fixes angular#36346.
devversion
added a commit
to devversion/angular
that referenced
this issue
Apr 2, 2020
In rare cases a project with configured `rootDirs` that has imports to non-existent identifiers could fail in the migration. This happens because based on the application code, the migration could end up trying to resolve the `ts.Symbol` of such non-existent identifiers. This isn't a problem usually, but due to a upstream bug in the TypeScript compiler, a runtime error is thrown. This is because TypeScript is unable to compute a relative path from the originating source file to the imported source file which _should_ provide the non-existent identifier. An issue for this has been reported upstream: microsoft/TypeScript#37731. The issue only surfaces since our migrations don't provide an absolute base path that is used for resolving the root directories. To fix this, we ensure that we never use relative paths when parsing tsconfig files. More details can be found in the TS issue. Fixes angular#36346.
devversion
added a commit
to devversion/angular
that referenced
this issue
Apr 2, 2020
In rare cases a project with configured `rootDirs` that has imports to non-existent identifiers could fail in the migration. This happens because based on the application code, the migration could end up trying to resolve the `ts.Symbol` of such non-existent identifiers. This isn't a problem usually, but due to a upstream bug in the TypeScript compiler, a runtime error is thrown. This is because TypeScript is unable to compute a relative path from the originating source file to the imported source file which _should_ provide the non-existent identifier. An issue for this has been reported upstream: microsoft/TypeScript#37731. The issue only surfaces since our migrations don't provide an absolute base path that is used for resolving the root directories. To fix this, we ensure that we never use relative paths when parsing tsconfig files. More details can be found in the TS issue. Fixes angular#36346.
devversion
added a commit
to devversion/angular
that referenced
this issue
Apr 3, 2020
In rare cases a project with configured `rootDirs` that has imports to non-existent identifiers could fail in the migration. This happens because based on the application code, the migration could end up trying to resolve the `ts.Symbol` of such non-existent identifiers. This isn't a problem usually, but due to a upstream bug in the TypeScript compiler, a runtime error is thrown. This is because TypeScript is unable to compute a relative path from the originating source file to the imported source file which _should_ provide the non-existent identifier. An issue for this has been reported upstream: microsoft/TypeScript#37731. The issue only surfaces since our migrations don't provide an absolute base path that is used for resolving the root directories. To fix this, we ensure that we never use relative paths when parsing tsconfig files. More details can be found in the TS issue. Fixes angular#36346.
devversion
added a commit
to devversion/angular
that referenced
this issue
Apr 3, 2020
In rare cases a project with configured `rootDirs` that has imports to non-existent identifiers could fail in the migration. This happens because based on the application code, the migration could end up trying to resolve the `ts.Symbol` of such non-existent identifiers. This isn't a problem usually, but due to a upstream bug in the TypeScript compiler, a runtime error is thrown. This is because TypeScript is unable to compute a relative path from the originating source file to the imported source file which _should_ provide the non-existent identifier. An issue for this has been reported upstream: microsoft/TypeScript#37731. The issue only surfaces since our migrations don't provide an absolute base path that is used for resolving the root directories. To fix this, we ensure that we never use relative paths when parsing tsconfig files. More details can be found in the TS issue. Fixes angular#36346.
kara
pushed a commit
to angular/angular
that referenced
this issue
Apr 6, 2020
…#36367) In rare cases a project with configured `rootDirs` that has imports to non-existent identifiers could fail in the migration. This happens because based on the application code, the migration could end up trying to resolve the `ts.Symbol` of such non-existent identifiers. This isn't a problem usually, but due to a upstream bug in the TypeScript compiler, a runtime error is thrown. This is because TypeScript is unable to compute a relative path from the originating source file to the imported source file which _should_ provide the non-existent identifier. An issue for this has been reported upstream: microsoft/TypeScript#37731. The issue only surfaces since our migrations don't provide an absolute base path that is used for resolving the root directories. To fix this, we ensure that we never use relative paths when parsing tsconfig files. More details can be found in the TS issue. Fixes #36346. PR Close #36367
kara
pushed a commit
to angular/angular
that referenced
this issue
Apr 6, 2020
…#36367) In rare cases a project with configured `rootDirs` that has imports to non-existent identifiers could fail in the migration. This happens because based on the application code, the migration could end up trying to resolve the `ts.Symbol` of such non-existent identifiers. This isn't a problem usually, but due to a upstream bug in the TypeScript compiler, a runtime error is thrown. This is because TypeScript is unable to compute a relative path from the originating source file to the imported source file which _should_ provide the non-existent identifier. An issue for this has been reported upstream: microsoft/TypeScript#37731. The issue only surfaces since our migrations don't provide an absolute base path that is used for resolving the root directories. To fix this, we ensure that we never use relative paths when parsing tsconfig files. More details can be found in the TS issue. Fixes #36346. PR Close #36367
This is working as intended and providing right basePath and handing of paths is expected to be host/api user's responsibility. |
sheetalkamat
added
Working as Intended
The behavior described is the intended behavior; this is not a bug
and removed
Bug
A bug in TypeScript
labels
Jul 8, 2020
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
TypeScript Version: 3.8.3
Search Terms:
TypeError: Cannot read property 'lastIndexOf' of undefined
getPathRelativeToRootDirs
throws due to missingundefined
guard.rootDirs
are not absolute.Code
An easy reproduction can be found here: https://github.com/devversion/ts-checker-root-dir-runtime-exception.
Steps:
yarn
node ./test.js
.Explanation on what is happening:
Currently when developers parse a tsconfig using
ts.parseJsonConfigFileContent
, a base path needs to be specified. If that base path is not an absolute file path, the type checker can faildown the road when it tries to compute relative paths based on
rootDirs
.This can be observed when the relative tsconfig path is made absolute in the
test.js
file. At this point, the type checker will not throw, andgetSymbolAtLocation
works as expected.Expected behavior:
Calling
typeChecker.getSymbolAtLocation
(as seen intest.js
) should never cause a runtime exception. HencegetPathRelativeToRootDirs
should be updated to catch cases where the relative path cannot be computed (i.e.undefined
is returned).Similarly, I'd expect
ts.parseJsonConfigFileContent()
to either throw if no absolute base path is specified, or expect the path to be resolved based on the CWD. Not sure if that makes sense though.Actual behavior:
It throws with a runtime exception. See error snippet above. The error surfaces because no relative path can be computed in
getPathRelativeToRootDirs
. This is because (as explained above), the root directories are not absolute paths, andgetPathRelativeToRootDirs
does not guard againstundefined
being returned fromgetRelativePathIfInDirectory
.Related Issues:
The text was updated successfully, but these errors were encountered: