Closed kalvenschraut closed 1 year ago
@kalvenschraut Shouldn't the file extensions be changed to .js
? With this change, we are still outputting .ts
, which does not comply with the ESM resolution spec.
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 allowImportingTsExtensions
on it is assumed TSC is not the one building the files and some external bundler is like vite.
Was introduced along with the bunder module resolution https://github.com/microsoft/TypeScript/pull/51669
I am using swc
to compile TypeScript code with certain settings in my tsconfig. Specifically, I have allowImportingTsExtensions
set to true
and moduleResolution
set to nodenext
. Here is a simplified version of my tsconfig:
{
"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 import { tomorrow } from '~/utils/date.ts';
in my code, it produces different results depending on the case:
// 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 swc
because it doesn't have the option to preserve file extensions.
Additionally, fixing .d.ts
files is not working for me anymore with both the current version of tsc-alias
and your branch. The paths in my code have .ts
extensions but they still reference the .ts
files even after running tsc-alias
. 🤷
I believe that the allowImportingTsExtensions
option is causing d.ts files to reference .ts files, which could be the source of the problem. 🤔
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.
I believe that the allowImportingTsExtensions option is causing d.ts files to reference .ts files, which could be the source of the problem. 🤔
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.
As of typescript 5.0, typescript added
allowImportingTsExtensions
and 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