Note: if you're here following a link from our docs about experimentalResolver
, you know that our docs for this feature are currently quite limited. Feel free to experiment and ask questions in Discussions or on Discord. This epic tracks the development work to finish all the resolver features and eventually promote them out of experimental status.
Describes state of our main
branch, may not be published to npm yet
module: NodeNext
, esm: true
, and experimentalResolver: true
. Everything works: cjs, cts, mjs, mts, with or without file extensions in import specifiers, in CommonJS or ESM filesIn TS, you import the emitted output path, and the compiler resolves this to the input source. They might have different extensions or be in different directories.
In ts-node, we should do the same.
Creating an epic to link together all the related tickets and tasks to make this happen.
Related tickets in no particular order:Module._resolveFilename
hooks #1614It's been a while since I read the TS code.
I believe that TS creates a mapping from all source files to their emit paths. It can do this because it starts with a glob of all source files, then computes the output path for each in a loop.
Aside: Does this work with files not included in a files
array? Does it trigger inclusion of those files in compilation? If yes, that would violate my understanding above.
ts-node must do the opposite of TS: we start from a runtime require()
or import
request, then work backwards to a source TS file. We don't know if such a source file exists; we might be importing a non-compiled .js
file.
Mappings to keep in mind:
package.json
exports
package.json
main
node_modules
searchtsconfig.json
outDir
and rootDir
correspondencetsconfig.json
paths
tsconfig.json
baseUrl
tsconfig.json
rootDirs
Supported extensions are affected by:
resolveJsonModule
allowJs
jsx
TS >=4.5 supports mts, cts, mjs, cjs
moduleResolution or module?
break down this list by (a) those needed when resolving relative specifiers (b) those needed when resolving non-relative specifiers, such as foo
When resolving from ./dist/foo.js
to ./src/foo.ts
we have 2x options:
./dist/foo.js
and give it the compiled output of ./src/foo.ts
./dist/foo.js
./dist
-> ./src
mapping./dist
to ./src
./src/foo.ts
and give it the compiled output of ./src/foo.ts
./src/foo.ts
ts-node today does (B) but does not do most of the advanced resolution we'd be implementing in this epic.
(B) is closer to deno and probably what people want. __filename
and import.meta.url
will refer to the actual TS file being executed. This is technically slightly different than pre-compilation execution. However, my gut tells me users will be happier with an intuitive __filename
and won't mind the slight difference with pre-compilation.
Note: resolve hook is equivalent to _resolveFilename
, load hook is equivalent to compile()
hook
ignore
with resolver
If src/index.ts
is ignored and dist/index.js
resolves to src/index.ts
, should the resolver do that mapping?
wolverian, rafaelliu, ssalbdivad, alexilyaev, niieani and 2 moremickdekkers, franklevasseur, elmpp, LcsK, falkenhawk and 1 more
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4