-
Notifications
You must be signed in to change notification settings - Fork 104
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Native ESM support, possibly requiring integration with ts-node #122
Comments
just posted a similar issue but I am not sure if this repo is still maintained... |
@desmap you can be the one to do it! You can also stop using path mappings in your project. Probably wouldn't be much work since it's some find-and-replace of the import statements. What benefits do you hope to get from switching to native ESM? You'll be forcing your users to install a non-standard path mapping hook. |
It'd def debatable but I'd like it, check yarnpkg/berry#638 (comment) and yarnpkg/berry#638 (comment) for examples |
I had trouble getting module path mappings to work with ESM (using To use the loader code below, pass it to Custom loader code// (loader.ts)
// Uses tsconfig.json and createMatchPath (from tsconfig-paths lib) to implement a custom loader
// (resolve function) that applies path mappings like `@src/foo` --> `/path/to/app/build/src/foo.js`
// See also https://github.com/TypeStrong/ts-node/discussions/1450#discussion-3563207
import { existsSync } from 'fs';
import { readFile } from 'fs/promises';
import { basename, dirname, resolve as pathResolve } from 'path';
import { fileURLToPath } from 'url';
import { createMatchPath } from 'tsconfig-paths';
const __dirname = dirname(fileURLToPath(import.meta.url));
async function getTSConfig() {
const maxDepth = 32; // arbitrary
let depth = 0;
let tsConfigFile = pathResolve(__dirname, 'tsconfig.json');
while(!existsSync(tsConfigFile)) {
tsConfigFile = pathResolve(dirname(tsConfigFile), '..', basename(tsConfigFile));
depth++;
if (depth > maxDepth) {
throw Error(`maxDepth (${maxDepth}) exceeded while searching for tsconfig.json`);
}
}
return JSON.parse(await readFile(tsConfigFile, 'utf-8'));
}
const getMatchPathPromise = (async () => {
const tsConfig = await getTSConfig();
const baseUrl = tsConfig.compilerOptions.baseUrl || '.';
const outDir = tsConfig.compilerOptions.outDir || '.';
const absoluteBaseUrl = pathResolve(baseUrl, outDir);
const paths = tsConfig.compilerOptions.paths;
return createMatchPath(absoluteBaseUrl, paths);
})();
export async function resolve(specifier, context, defaultResolve) {
const matchPath = await getMatchPathPromise;
const mappedSpecifier = matchPath(specifier)
if (mappedSpecifier) {
specifier = `${mappedSpecifier}.js`
}
return defaultResolve(specifier, context, defaultResolve);
} |
@jacobq Also have a look at this solution TypeStrong/ts-node#1450 |
Yes, I saw it (hence why I mentioned it in my comment 😉). I probably should've mentioned that I am not actually using |
I wanted to mention new solution created by @charles-allen 4 days ago (TypeStrong/ts-node#1450 (comment)) |
This allows `ts-node` to be used to run TypeScript files without having to compile them with `tsc` first. It also adds the necessary configs, including `tsconfig-paths` for `paths` import-alias resolution. Unfortunately, this means we have to remove the `--experimental-module-resolution=node` since `ts-node` uses its own loader and thus form of resolving modules. See: Setup * https://medium.com/@jimcraft123hd/setting-up-path-alias-in-typescript-and-tsc-build-without-error-9f1dbc0bccd2 Issues with `ts-node`, ESM, and aliases * TypeStrong/ts-node#1007 - TypeStrong/ts-node#476 - dividab/tsconfig-paths#122 (comment) - TypeStrong/ts-node#1450 (comment) * TypeStrong/ts-node#1414 * TypeStrong/ts-node#995 - TypeStrong/ts-node#639 Node issues with ESM * https://nodejs.org/api/packages.html#determining-module-system * nodejs/node#37468
This allows `ts-node` to be used to run TypeScript files without having to compile them with `tsc` first. It also adds the necessary configs, including `tsconfig-paths` for `paths` import-alias resolution. Unfortunately, this means we have to remove the `--experimental-module-resolution=node` since `ts-node` uses its own loader and thus form of resolving modules. See: Setup * https://medium.com/@jimcraft123hd/setting-up-path-alias-in-typescript-and-tsc-build-without-error-9f1dbc0bccd2 Issues with `ts-node`, ESM, and aliases * TypeStrong/ts-node#1007 - TypeStrong/ts-node#476 - dividab/tsconfig-paths#122 (comment) - TypeStrong/ts-node#1450 (comment) * TypeStrong/ts-node#1414 * TypeStrong/ts-node#995 - TypeStrong/ts-node#639 Node issues with ESM * https://nodejs.org/api/packages.html#determining-module-system * nodejs/node#37468
This allows `ts-node` to be used to run TypeScript files without having to compile them with `tsc` first. It also adds the necessary configs, including `tsconfig-paths` for `paths` import-alias resolution. Unfortunately, this means we have to remove the `--experimental-module-resolution=node` since `ts-node` uses its own loader and thus form of resolving modules. See: Setup * https://medium.com/@jimcraft123hd/setting-up-path-alias-in-typescript-and-tsc-build-without-error-9f1dbc0bccd2 Issues with `ts-node`, ESM, and aliases * TypeStrong/ts-node#1007 - TypeStrong/ts-node#476 - dividab/tsconfig-paths#122 (comment) - TypeStrong/ts-node#1450 (comment) * TypeStrong/ts-node#1414 * TypeStrong/ts-node#995 - TypeStrong/ts-node#639 Node issues with ESM * https://nodejs.org/api/packages.html#determining-module-system * nodejs/node#37468
Closing in favor of TypeStrong/ts-node#1585 which will add native path mapping support to ts-node. |
In
ts-node
we released experimental support for native ECMAScript modules. To do this we needed to implement a customresolve()
loader hook. It is a copy-paste of node's built-in resolver, tweaked for our needs.TypeStrong/ts-node#1007
Is native ESM support on your radar? Do you have thoughts on how best to implement it for tsconfig-paths? I expect we will need to coordinate, since node only supports a single loader hook.
I see that the compiler itself can perform these resolutions via
ts.resolveModuleName
. Do you use that internally, or do you do something else?The text was updated successfully, but these errors were encountered: