TypeScript issues

[philkunz]

Relative import paths need explicit file extensions in ECMAScript imports when '--moduleResolution' is 'node16' or 'nodenext'. Did you mean './enums.js'?
Relative import paths need explicit file extensions in ECMAScript imports when '--moduleResolution' is 'node16' or 'nodenext'. Did you mean './watcher_handler.js'?
Relative import paths need explicit file extensions in ECMAScript imports when '--moduleResolution' is 'node16' or 'nodenext'. Did you mean './watcher_locker.js'?
Relative import paths need explicit file extensions in ECMAScript imports when '--moduleResolution' is 'node16' or 'nodenext'. Did you mean './watcher_poller.js'?

... and so on.

[fabiospampinato]

Maybe obvious, but how do I reproduce the issue? 🤔 Once compiled imported files seem to contain an extension already.

[fabiospampinato]

/cc @benmccann in case you know how to reproduce this problem.

[benmccann]

@fabiospampinato if you do npm install watcher and then open up node_modules/watcher/dist/types.d.ts you'll see that the compiled output does not have file extensions:

With #38, the file extensions are present in the compiled output

[philkunz]

Here are the compiler options to reproduce this:

"compilerOptions": {
"experimentalDecorators": true,
"useDefineForClassFields": false,
"target": "ES2022",
"module": "NodeNext",
"moduleResolution": "NodeNext",
"esModuleInterop": true,
"verbatimModuleSyntax": true
},

Until the fix is merged, there is a fixed version available at @tempfix/watcher, https://code.foss.global/tempfix/watcher

This error is present also in the dependencies of this package.

[SellersEvan]

Same issue here. I believe the extension name is required to be fully ESM compatible.

[benmccann]

Yeah, it sounds like it's a bug in tsex, which is used to package this library: https://github.com/fabiospampinato/tsex

[fabiospampinato]

I finally had the time to look into this, but it's going to take a little longer to fix it. A brain dump:

• This commit in tsex, the convenience library I'm using to compile my npm packages, should make sure imports in .d.ts files get rewritten to have an extension too, which is basically the root problem here.
• There was an interesting comment in there though, that said: "// We don't actually want to fully resolve the path for declaration files", because I guess I had tried rewriting imports in declaration files already, but TS was complaining if I was importing from .d.ts files explicitly, but it wasn't complaining if I didn't specify the extension, so I just left those imports be. Apparently you need to say that you are importing from a .js file, then TS will resolve the .d.ts file by itself, you can't just tell it what the .d.ts file is, which doesn't make too much sense to me as far as "being explicit" goes, like it makes no sense to do an import type from a .js file to begin with, but whatever, I guess I know that now.
• Switching the module compiler flag to node16 causes TS to no longer emit pure ESM code, so that's not happening, as emitting pure ESM only is what I want.
• This explicit imports problem is kinda recursive, just updating tsex in watcher doesn't fix it because there's another type "error" like that in a dependency that watcher imports, so I need to go over all my packages and update them all to totally fix this issue.
• Also I was doing an unrelated weird hack in tsex to make sure I wouldn't have to specify source and output directories in every tsconfig.json of every package I maintain, but TS v5.5.0 incidentally added a template variable that addresses this issue properly, so that's another good reason to go over all my packages and update them anyway, I guess.

So yeah I need to go over these packages, hopefully I can get it done by tomorrow, it may take a little longer than that. In general I'd recommend putting skipLibCheck: true in your tsconfig.json, not using it is kinda unworkable imo, every non-patch release of TS could have breaking changes, one can't expect all dependencies to pass all checks in whatever arbitrary version of TS you are using.

[benmccann]

Switching the module compiler flag to node16 causes TS to no longer emit pure ESM code, so that's not happening, as emitting pure ESM only is what I want.

Oh, where is the output non-ESM with this flag? I hadn't noticed anything non-ESM with #38, but would be curious to learn more so I can keep an eye out for it in other projects I work on

[fabiospampinato]

Oh, where is the output non-ESM with this flag?

Unfortunately I can no longer seem to be able to reproduce the issue 🙃 I don't know if I had done something wrong the other day or what.

---

This issue should be fixed by this commit (and doing the same thing for everything watcher depends on). I'll double-check after I make a release before closing this issue.