Fix type definitions for moduleResolution nodenext

[trygveaa]

When importing this library in a project using moduleResolution nodenext, the types would give errors because the import paths were missing the file extension which is required for moduleResolution nodenext. Therefore we have to add .js to all imports of local files.

See developit/microbundle#1019 (comment) and the issues that comment links to for some more detailed explanation of this.

I also changed moduleResolution to nodenext in the tsconfig because when it's set to node, typescript won't give errors for missing file extensions which means they are easy to forget. With it set to nodenext, you will get an error if an import is missing the file extension. As far as I can see, changing this doesn't change the build output.

Depends on donmccurdy/property-graph#70 and donmccurdy/KTX-Parse#55

Fixes #824

[donmccurdy]

Hi @trygveaa, thank you! Do you know whether the problem here is new with the v3.0 release, or was the library also incompatible with nodenext in v2.5?

[trygveaa]

Hi @trygveaa, thank you! Do you know whether the problem here is new with the v3.0 release, or was the library also incompatible with nodenext in v2.5?

Yes, the problem was introduced in v3.0.0 when "type": "module" was specified in package.json as node and typescript requires imports to have a file extension when type is module. So I don't get any type errors with v2.5.1 even though my own project uses moduleResolution nodenext, because v2.5.1 was treated as CommonJS and then file extensions is not necessary.

Btw, I see that the tests failed in CI. This is likely because the dependency on the two other PRs as mentioned in the description (though I did have some issues with some of the tests locally, but I see the same issues in main).

[donmccurdy]

Thanks @trygveaa! I've merged the other PRs and updated their npm versions on the main branch here, could you rebase the PR?

[trygveaa]

Great! I rebased it now.

[donmccurdy]

Thanks so much for the investigation and working through all the changes here and upstream!

If microbundle were to (someday) start allowing us to bundle the .d.ts files, this issue should go away because the generated typings wouldn't contain any relative imports — does that sound correct? Quite an interesting situation, I wish I could un-read some of those TypeScript threads... 😅

[trygveaa]

Thanks so much for the investigation and working through all the changes here and upstream!

No problem, thanks for creating this useful library :)

If microbundle were to (someday) start allowing us to bundle the .d.ts files, this issue should go away because the generated typings wouldn't contain any relative imports — does that sound correct? Quite an interesting situation, I wish I could un-read some of those TypeScript threads... sweat_smile

Yes, without any imports in the .d.ts files, there wouldn't be a problem. But according to this comment it doesn't sound like microbundle is going to do that:

While merging declaration files could be nice, it's not without it's own complexities and it would be a move away from tsc which increases the maintenance burden. Outputting multiple .d.ts files for a single output is default tsc behavior, it's not a choice we made or anything.

Also, having .js extensions on imports is what both browsers and node expect now, so I think that's the right thing to do in your code base regardless. It makes a bit less sense when using typescript, but it seems typescript is pretty adamant on not rewriting imports, so that't the way to go for typescript files as well.