Ensure .js extensions are present with Typescript 5

[mattjennings]

Describe the problem

This is a Typescript problem (see this, and this), but package is affected by this because it produces ESM javascript.

Say your src/lib folder has two files in it: index.ts and store.ts. Your index.ts looks like this:

export { myStore } from './store'

When you compile with svelte-kit package, the result is this:

export { myStore } from './store'

Because there's no .js file extension, this is will likely fail in ESM. SvelteKit projects seem to handle this fine (I'm not sure why), but projects using webpack for example will fail with the following error:

Module not found: Error: Can't resolve './store' in 'node_modules/your-lib'
Did you mean 'store.js'?
BREAKING CHANGE: The request './store' failed to resolve only because it was resolved as fully specified
(probably because the origin is a '*.mjs' file or a '*.js' file where the package.json contains '"type": "module"').
The extension in the request is mandatory for it to be fully specified.
Add the extension to the request.

Describe the proposed solution

Frustratingly, it seems Typescript's stance on this is to add .js to your file extensions in your .ts files. This works when compiling through package, but will not work if you want to consume src/lib yourself within the kit project (i.e under /routes, if you wanted to set up docs or something).

The only way around this that I can think of is to add .js extensions in a post-compilation script. Similar to how tsc-esm does it. It's dumb that kit has to care about this, but I think it's going to be a common gotcha for many library authors otherwise.

Alternatives considered

• Compiling to commonjs but... no thanks

Importance

would make my life easier

Additional Information

In that tsc-esm package, it uses a utility file from grubber to add the .js extensions. I wrote up a script and ran it against my package output:

import patchJsImports from '@digitak/grubber/library/utilities/patchJsImports.js'

patchJsImports('./package')

and it worked on everything except my index.js file, but I haven't looked much further into that.

[mattjennings]

For anyone running into the issue for the meantime, I was able to get .js extensions added by installing ts-patch and using typescript-transform-extensions. Obviously not the ideal solution, but it will work for now.

[ignatiusmb]

There's a lot to unpack in that TS issue, but I kind of agree with their final decision. There's also a summary of that thread from microsoft/TypeScript#16577 (comment). I'm not sure what we should do for package as we are not doing any bundling step here, module resolution works as expected for almost everything else I know, except (which you mentioned) that Webpack template. Which makes me think that this should be resolved on Webpack's loader side. I'm also moving this to p2 for reasons that there's not a lot users that uses Svelte with Webpack, and it's plugin isn't as well maintained as Rollup or Vite.

Can you also elaborate how adding .js breaks usage within the kit project itself? What happens if you write it in index.js instead of index.ts? If that works, this might need to be resolved on Vite or the vite-plugin-svelte's side.

[mattjennings]

The reason .js imports won't work within the kit project itself is because that .js file doesn't exist yet (it will only be there post-compilation in the output folder). So if you run svelte-kit package, the .js file will exist in the output and that will all be fine when consumed. But if you're importing src/lib internally in your routes, since it's just .ts files, there won't be any .js file to import and vite will throw an error. This would go for any bundler, really.

Since ESM spec requires import extensions I think this could be another QoL thing package does for you even though it's a result of using typescript. However, like you said, rollup/vite handle this gracefully, so maybe it's fine to leave it up to the bundler. It's just a bit of extra burden on library maintainers using package to communicate this, even if the webpack + svelte userbase is low.

[dummdidumm]

I don't understand. If I import src/libs in src/routes from the same project I don't experience any errors.

(Accidental close)

[mattjennings]

Here's a repo demonstrating the problem: https://github.com/mattjennings/svelte-kit-package-extensions-bug

[dummdidumm]

Ok I understand - you're stuck in an either-or situation. Either make it work for webpack, or work internally, but not both.

[dummdidumm]

People authoring packages can solve this now by using node 16 / nodenext. They need to change the following settings in their tsconfig.json:

{
  "compilerOptions": {
    // ...
    "moduleResolution": "nodenext"
  }
}

Support for this will land in the next release of Svelte language-tools, I'll update this message once it's released.

I don't think we should change this setting for all users to this though, because then everyone is required to adhere to the new node resolution rules (which means explicit file endings for relative imports), not just package authors.
I therefore think we need another option in create-svelte which let's you chose if you want to create a package or an app. This would also solve the confusion around "what's this package command in my scripts, and why does it prompt me to install other stuff first in order to use it?"

[NatoBoram]

Using "moduleResolution": "NodeNext", I have an error with import { page } from '$app/stores':

Cannot find module $app/stores or its corresponding type declarations.

Do you know how I can fix this while still using "moduleResolution": "NodeNext"?

• [fix] Adjust type imports to satisfy TS NodeNext moduleResolution kit#5360

Importing .ts utility files while specifying .js crashes the commands vite dev, vite build and vite preview. I can hide them behind an index.ts file and that sometimes seems to work fine, but it'd be nice to not have to do that since we then have to keep updated that index.ts manually.

• Can't build SvelteKit component libraries with "moduleResolution": "NodeNext" kit#5387

[dummdidumm]

Could you create a new issue for this with a reproduction?

[dummdidumm]

I'm not sure that "moduleResolution": "Node16" is the best for us in the long run. Many people will be confused by that. I wonder if it's worth the trouble to use the transform API of ts.transpileModule to modify the relative imports of all Svelte/JS/TS files and rewrite them so that they satisfy the strict node resolution.

[dummdidumm]

TypeScript will (in 5.0? don't know) ship more fine grained module resolution flags, which hopefully solve this issue.

[benmccann]

We set NodeNext for libraries now:

https://github.com/sveltejs/kit/blob/b47794069dbec0b1b7d5af75b42614f3b46b0811/packages/create-svelte/shared/%2Bskeletonlib%2Btypescript/tsconfig.json#L13

[benmccann]

See also sveltejs/kit#12163