feature: Requesting support for node16/nodenext module resolution
kf6kjg opened this issue · comments
EDIT: Fixed in #1400 - thanks @carlocorradini!
Description
When using this library in a project that has the TSConfig setting moduleResolution
set to node16
the TS compiler throws errors on every import
and export ... from
call.
Example:
../../node_modules/type-graphql/dist/index.d.ts(1,15): error TS2834: Relative import paths need explicit file extensions in EcmaScript imports when '--moduleResolution' is 'node16' or 'nodenext'. Consider adding an extension to the import path.
Proposed solution
- Change the
tsconfig.json#/compilerOptions/moduleResolution
setting tonode16
. - Bulk alter the codebase to correct the
import
andexport
paths to have the full path to the target file with the extension. - Manually fix the outliers in the code: converting implicit
index.js
into explicit being one such.
This should have no deleterious effect since, as far as I am aware, no version of TS or Node cared about having the filename and extension until ES6 came along.
This feature is already available in PR #1400
We have to wait till it is merged and published :)
I'd read through that PR to see if it had this before posting, but not checked the code. So am I correct you are resolving this via using the @/
paths option so that you can use absolute paths instead of relative ones, thus bypassing the error without switching to the node16
module resolution strategy?
Nope.
The code supports both CJS and ESM.
Moreover, all absolute paths are transformed to relative.
You can check it by executing:
npm run build
If something is not clear let me know and I'll try to explain it better 🥳
Ok, so I checked out the maintainability
branch from your repo @carlocorradini. I executed npm ci && npm run build
and inspected the compiled code in the build
folder. What I found is that the result still causes the error that thsi ticket was opened to address.
For example, the import in build/typings/schema/build-context.d.ts
given below will trigger the error TS2834
mentioned in the OP.
import { IOCContainer } from "../utils/container";
If instead that compiled to the following it would not cause the error.
import { IOCContainer } from "../utils/container.js";
We can have .js
in declarations too.
Wait 5 minutes. I'll push a fix and then you can try ok
@kf6kjg Try now
That looks good!
@kf6kjg Nice
Next up is looking for / opening a ticket for moving away from the types being in a separate folder to solve the other problem I'm having... :P
What are the other problems?
I've created #1442 to track that problem space as it's orthogonal to this ticket. :)
I think this can be closed by #1400 🔒
@carlocorradini Can you share your example repo with ESM usage?