support resolving aliases that have a .ts extension #178
Comments
kalvenschraut
added a commit
to RTVision/tsc-alias
that referenced
this issue
May 17, 2023
justkey007
pushed a commit
that referenced
this issue
May 23, 2023
|
@kalvenschraut Shouldn't the file extensions be changed to |
|
As of typescript 5.0 you can have .ts as the extension. Typescript leaves the extension as is meaning that the .d.ts files are going have the .ts extension still. This is fine because typescript will still resolve the files correctly. With Was introduced along with the bunder module resolution microsoft/TypeScript#51669 |
|
I am using {
"module": "esnext",
"moduleResolution": "nodenext",
"declaration": true,
"emitDeclarationOnly": true,
"allowImportingTsExtensions": true,
"paths": {
"~/*": ["./*"]
}
}My goal is to provide an output that has correct paths and conforms to the esm resolution spec. However, I'm not sure if I'm missing something or if my assumptions are incorrect. When I use something like // Using tsc-alias v1.8.6 will not change the path.
import { tomorrow } from '~/utils/date.ts';
// Using tsc-alias from the master branch with #178 applied will resolve the alias but keep the extension.
import { tomorrow } from '../utils/date.ts';
// Using the swc paths config option will resolve the alias correctly but it will drop the extension.
import { tomorrow } from '../utils/date';
// The desired output is a correct path with a file extension matching .js files. Therefore, I'm currently forced to use tsc-alias on files produced by swc in a previous step.
import { tomorrow } from '../utils/date.js';I'm struggling to see how changes made in #179 are supposed to work since having any extension other than .js, .mjs, .cjs or .json will result in an 'Unsupported File Extension' error. I would greatly appreciate any insight on the matter. Thanks |
|
Are you using tsc-alias to resolve aliases in built js files too? In my setup I only do it for .d.ts generated files. I will give a little more detailed response tomorrow after I wake up in ~9 hrs, but my setup is primarily tsup for compiling simpler codebases and vite for our frontend codebases. Tsup uses esbuild to do the compilation, I don't have a ton of experience with SWC. Mainly know it is used because of of decorator meta support in esbuild being lacking. |
|
Yep. I need to fill another issue for I believe that the |
log |
|
Yesterday was a busy day for me, sorry for promising something I didn't get to. From what I understand of tsc-alias, it will try find the corresponding file it is resolving. So if you import something with an alias, it should find the file using the resolve path of the alias defined in tsconfig. I know it checks multiple extensions that it could be such as .d.ts, .js.
That is my understand also. TSC is expecting your bundler to replace the .ts with the appropriate file extension in the built file so this is something I assume SWC would need to handle. Vite/esbuild do for me. As for the .d.ts files having the .ts extension, seems to be fine for me. As long as the resolved import path has a .d.ts file where it is looking for the .ts file. If you had both a .d.ts and a .ts file of the same name then the .ts file would be picked, but I personally see this as an odd setup. Typically .d.ts and js files are together since they are the built artifacts. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
As of typescript 5.0, typescript added
allowImportingTsExtensionsand then leaves the .ts extension in the .d.ts file. Because of this tsc-alias is not finding the .d.ts files when it tries to verify the file exists before replacing the alias.Will submit PR for this shortly. Handling same way as .js/.json
The text was updated successfully, but these errors were encountered: