May fail with symlinks #107
Labels
Bug
Something isn't working
Comments
nonara
added a commit
that referenced
this issue
Jun 16, 2021
- Several improvements were made for speed and efficiency. - Now accommodating for new TS empty baseURL provision (closes #109) - Pre-checking necessity before overwriting paths (closes #110) - Rewrote core resolution methodology to: - Properly handle implicit indexes (closes #106) - Properly handle implicit sub-package indexes set via package.json 'main' #108) - Not follow symlinks (#107) - Resolve from output path as opposed to SourceFile path (#103)
nonara
added a commit
that referenced
this issue
Jun 16, 2021
- Several improvements were made for speed and efficiency. - Now accommodating for new TS empty baseURL provision (closes #109) - Pre-checking necessity before overwriting paths (closes #110) - Rewrote core resolution methodology to: - Properly handle implicit indexes (closes #106) - Properly handle implicit sub-package indexes set via package.json 'main' #108) - Not follow symlinks (#107) - Resolve from output path as opposed to SourceFile path (#103)
nonara
added a commit
that referenced
this issue
Jun 16, 2021
- Several improvements were made for speed and efficiency. - Now accommodating for new TS empty baseURL provision (closes #109) - Pre-checking necessity before overwriting paths (closes #110) - Rewrote core resolution methodology to: - Properly handle implicit indexes (closes #106) - Properly handle implicit sub-package indexes set via package.json 'main' #108) - Not follow symlinks (#107) - Resolve from output path as opposed to SourceFile path (#103)
nonara
added a commit
that referenced
this issue
Jun 16, 2021
- Several improvements were made for speed and efficiency. - Now accommodating for new TS empty baseURL provision (closes #109) - Pre-checking necessity before overwriting paths (closes #110) - Rewrote core resolution methodology to: - Properly handle implicit indexes (closes #106) - Properly handle implicit sub-package indexes set via package.json 'main' #108) - Not follow symlinks (#107) - Resolve from output path as opposed to SourceFile path (#103)
|
Sorted in v3.0 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
In looking into TS compiler's resolver code, I have discovered an internal property called
originalPathin theResolvedModuleFulltype returned by theresolveModuleNameAPI function. This is the function we rely on to get our resolved path for output.Looking further into the code, it seems that the
originalPathvalue is set when thecompilerOptions.preserveSymlinksoption isfalseintsconfig.jsonand the resolved module is a symlink.At present, if a resolved module is a symlink, our transformer output will use the symlink path as opposed to the original, which could cause issues. To mitigate, we should prefer
originalPath(when it is available) to avoid this issue.Simply put, this will keep us from "following" symlinks during our own resolution.
The text was updated successfully, but these errors were encountered: