Giter Club home page Giter Club logo

tsm's People

Contributors

ai avatar antongolub avatar lukeed avatar niieani avatar saitonakamura avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

tsm's Issues

pnpm support

When I call (or do the same in package.scripts but without pnpx):

pnpx tsm node_modules/.bin/uvu . '\\.test\\.(ts|js)$'

I got in pnpm:

TypeError [ERR_UNKNOWN_FILE_EXTENSION]: Unknown file extension "" for /home/ai/Dev/nanostores/node_modules/.bin/uvu
    at new NodeError (node:internal/errors:371:5)
    at Object.file: (node:internal/modules/esm/get_format:72:15)
    at defaultGetFormat (node:internal/modules/esm/get_format:85:38)
    at defaultLoad (node:internal/modules/esm/load:22:14)
    at load (file:///home/ai/Dev/nanostores/node_modules/.pnpm/[email protected]/node_modules/tsm/loader.mjs:1:1017)
    at async ESMLoader.load (node:internal/modules/esm/loader:353:20)
    at async ESMLoader.moduleProvider (node:internal/modules/esm/loader:274:47)
    at async link (node:internal/modules/esm/module_job:70:21) {
  code: 'ERR_UNKNOWN_FILE_EXTENSION'
}

Reproduction:

git clone [email protected]:nanostores/nanostores.git
git checkout chore/pnpm
pnpm unit

Upgrade `esbuild` for const type parameters?

Hey @lukeed πŸ‘‹ hope you're well!

It seems that [email protected] added support for TS 5.0 const type parameters

Currently, [email protected] depends on esbuild@^0.15.16, and runs into errors like Expected identifier but found "const":

✘ [ERROR] Expected identifier but found "const"

    /Users/k/p/project/index.ts:29:40:
      29 β”‚ export async function getProjectFixture<const Fixture extends { id: number }>(
         β•΅                                         ~~~~~

/Users/k/p/project/node_modules/tsm/node_modules/esbuild/lib/main.js:1575
  let error = new Error(`${text}${summary}`);
              ^

Error: Transform failed with 1 error:
/Users/k/p/project/index.ts:29:40: ERROR: Expected identifier but found "const"
    at failureErrorWithLog (/Users/k/p/project/node_modules/tsm/node_modules/esbuild/lib/main.js:1575:15)
    at /Users/k/p/project/node_modules/tsm/node_modules/esbuild/lib/main.js:814:29
    at responseCallbacks.<computed> (/Users/k/p/project/node_modules/tsm/node_modules/esbuild/lib/main.js:680:9)
    at handleIncomingPacket (/Users/k/p/project/node_modules/tsm/node_modules/esbuild/lib/main.js:735:9)
    at Socket.readFromStdout (/Users/k/p/project/node_modules/tsm/node_modules/esbuild/lib/main.js:656:7)
    at Socket.emit (node:events:513:28)
    at addChunk (node:internal/streams/readable:324:12)
    at readableAddChunk (node:internal/streams/readable:297:9)
    at Readable.push (node:internal/streams/readable:234:10)
    at Pipe.onStreamRead (node:internal/stream_base_commons:190:23)

Proposed Solution

What do you think about upgrading to esbuild@^0.18.6?

Seems like forcing the upgrade to the transitive esbuild dependency via Yarn Resolutions works in our project and enables the const type parameters πŸ‘

support `.js` extension for imports in `.ts` files

It is supported in ts-node/esm and according to typescript that's the recommended way to import
https://twitter.com/orta/status/1444958295865937920

foo.ts

import bar from './bar.js'  // bar.js does not exist on disk, it is the transpilation result of bar.ts

Right now this fails with ENOENT, here's how it looks like in uvu's typescript.module example when you use math.ts and utils.ts instead of .js

devDependencies:
+ loadr 0.1.1
+ tsm 2.0.0
+ uvu 0.5.1
dominikg@mb14:~/develop/uvu/examples/typescript.module$ pnpm test

> @ test /home/dominikg/develop/uvu/examples/typescript.module
> tsm node_modules/uvu/bin.js tests

(node:8503) ExperimentalWarning: --experimental-loader is an experimental feature. This feature could change at any time
(Use `node --trace-warnings ...` to show where the warning was created)
Error: ENOENT: no such file or directory, open '/home/dominikg/develop/uvu/examples/typescript.module/src/math.js'

Deprecated hooks

On the lastest node.js version the following error is thrown:

DeprecationWarning: Obsolete loader hook(s) supplied and will be ignored: getFormat, transformSource

Meaning some features will not work properly unless those hooks are moved into the new load hook.

".mts" and ".cts" default format

Shouldn't the config have these defaults to follow the TypeScript logic?

{
  ".mts": {
    "format": "esm"
  },
  ".cts": {
    "format":  "cjs"
  }
}

One could also argue that these extensions format shouldn't even be configurable and force these formats, just as .cjs forces commonjs and .mjs forces ecmascript modules

Transformation does not support plugins; Not working for Relay

πŸ‘‹ thanks for amazing tool. Being using it for quite a while and everything was fine... until today :(

Invariant Violation: graphql: Unexpected invocation at runtime. 
Either the Babel transform was not set up, or it failed to identify this call site. 
Make sure it is being used verbatim as `graphql`. 
Note also that there cannot be a space between graphql and the backtick that follows.
..../node_modules/relay-runtime/lib/query/GraphQLTag.js:25:52

We have 3 different ways to run our code:

  • via babel, where babel plugin does the job
  • via esbuild, where we have another plugin doing required transformations
  • via node/tms where... we cannot hook into transformation process and change a few bits and pieces unless we override Module._compile in the same way you do to apply required transformations.

In order to provide flexibility for the end solution I want to steer issue from "not supporting plugins"(transformSync just dont support it) to the actual problem I am facing with graphql.

Similar problem might occur while using any library which heavy relies on babel transformation step, and might be not for all of them tsm should work (and it does not right now).

But is there anything we can do?

Is there a minimal repo example?

Getting this error

/node_modules/tsm/loader.mjs:1
import{existsSync as S,promises as j}from"fs";import{fileURLToPath as p,URL as g}from"url";import*as d from"./utils.js";let u,m,l=d.$defaults("esm"),x=l.file&&import("file:///"+l.file);async function y(){let t=await x;return t=t&&t.default||t,d.$finalize(l,t)}const w=/\.\w+(?=\?|$)/,h=/\.[mc]?tsx?(?=\?|$)/,T=/\.([mc])?js$/;async function f(t){u=u||await y();let[r]=w.exec(t)||[];return u[r]}function c(t){let r=p(t);if(S(r))return t}const b=new g("file:///"+process.cwd()+"/");export const resolve=async function(t,r,e){if(/^\w+\:?/.test(t))return e(t,r,e);let o,a,n,s,i=new g(t,r.parentURL||b);if(o=w.exec(i.href)){if(n=o[0],!r.parentURL||h.test(n))return{url:i.href};if(s=c(i.href),s)return{url:s};if(T.test(n)&&h.test(r.parentURL))return s=i.href.substring(0,a=o.index),(s=c(s+n.replace("js","ts")))?(a+=n.length,a>i.href.length&&(s+=i.href.substring(a)),{url:s}):e(t,r,e)}u=u||await y();for(n in u)if(s=c(i.href+n),s)return{url:s};return e(t,r,e)},load=async function(t,r,e){let o=await f(t);if(o==null)return e(t,r,e);let a=o.format==="cjs"?"commonjs":"module",n=p(t),s=await j.readFile(n);m=m||await import("esbuild");let i=await m.transform(s.toString(),{...o,sourcefile:n,format:a==="module"?"esm":"cjs"});return{format:a,source:i.code}},getFormat=async function(t,r,e){let o=await f(t);return o==null?e(t,r,e):{format:o.format==="cjs"?"commonjs":"module"}},transformSource=async function(t,r,e){let o=await f(r.url);return o==null?e(t,r,e):(m=m||await import("esbuild"),{source:(await m.transform(t.toString(),{...o,sourcefile:r.url,format:r.format==="module"?"esm":"cjs"})).code})};
                                                                                                                                    ^

TypeError: d.$defaults is not a function...

and I'm wondering if I am missing some setup or something wrong with my local env.

What would help me troubleshoot is if either there was an example repo or if there was a command like tsm --init for creating any boilerplate. I appreciate there might not be any boilerplate but even then would be good to have that validated by the example. So that I'm not second guessing things like "do I need tsconfig.json?"

Force to run as ESM

Hey, I'm using a build setup like https://www.sensedeep.com/blog/posts/2021/how-to-create-single-source-npm-module.html to support both ESM and CJS but that seems to cause an issue with https://github.com/lukeed/uvu which seems to come from tsm when looking at the stack trace.

The TLDR of the above article is that instead of your package.json having a type property you defer it into the distribution folder. So you have dist/cjs/package.json and dist/esm/package.json files which indicate how to treat the loading. I assume that tsm decides if it should use require or import based on the type property in the package.json file.

Is there any way to force tsm to run as if the package.json file had a type property that is set to module?

> @payvo/[email protected] test /Users/brianfaust/Work/sdk/packages/ada
> uvu -r tsm source .test.js

/Users/brianfaust/Work/sdk/packages/ada/source/address-list.service.test.js:1
import { assert, test } from "@payvo/sdk-test";
^^^^^^

SyntaxError: Cannot use import statement outside a module
    at Object.compileFunction (node:vm:352:18)
    at wrapSafe (node:internal/modules/cjs/loader:1031:15)
    at Module._compile (node:internal/modules/cjs/loader:1065:27)
    at Module._extensions..js (node:internal/modules/cjs/loader:1153:10)
    at Object.loader (/Users/brianfaust/Work/sdk/common/temp/node_modules/.pnpm/[email protected]/node_modules/tsm/require.js:1:1052)
    at Module.load (node:internal/modules/cjs/loader:981:32)
    at Function.Module._load (node:internal/modules/cjs/loader:822:12)
    at Module.require (node:internal/modules/cjs/loader:1005:19)
    at require (node:internal/modules/cjs/helpers:102:18)
    at /Users/brianfaust/Work/sdk/common/temp/node_modules/.pnpm/[email protected]/node_modules/uvu/run/index.js:9:3
 ELIFECYCLE  Test failed. See above for more details.

Doesn't handle package.json `imports` field

the chalk uses imports in the package.json. these start with a #. I'm not sure of the full semantics of how this "should" work. It might be as simple as switching this:

- if (/^\w+\:?/.test(ident)) return fallback(ident, context, fallback);
+ if (/^(\w+\:?|#)/.test(ident)) return fallback(ident, context, fallback);

but that might be too naive to work in every case.

It seems to be because the check function calls fileURLToPath from url, which strips the # and following text, meaning that the check function ends up just checking if the parentURL exists.

I think the full solution to this would be to, if there's a # at the start of the import, call fallback and then process the result of fallback, as it might resolve to a typescript file. It might be enough to just ignore any # files and assume that the package exposing them is not using typescript?

Repro Steps

  • mkdir imports-report && cd imports-repro
  • npm init -y
  • npm add chalk tsm
  • echo "import chalk from 'chalk';" > index.mjs
  • node --loader tsm index.mjs

you'll see

file:///<folder>/imports-repro/node_modules/chalk/source/index.js#supports-color.mts:7
const { stdout: stdoutColor, stderr: stderrColor } = supportsColor;
                ^

TypeError: Cannot destructure property 'stdout' of 'supportsColor' as it is undefined.
    at file:///<folder>/imports-repro/node_modules/chalk/source/index.js#supports-color.mts:7:17
    at ModuleJob.run (node:internal/modules/esm/module_job:193:25)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async Promise.all (index 0)
    at async ESMLoader.import (node:internal/modules/esm/loader:527:24)
    at async loadESM (node:internal/process/esm_loader:91:5)
    at async handleMainPromise (node:internal/modules/run_main:65:12)

Support TypeScript 4.9 `satisfies` operator

Hi @lukeed πŸ‘‹ Hope you are well.

It would be great to be able to use the TypeScript 4.9 satisfies operator!

However, currently, tsm throws an error when using satisfies:

import {AType} from '../a';

const a = 'abc' satisfies AType; // πŸ’₯ Expected ";" but found "satisfies"

Full error:

Error: R] Expected ";" but found "satisfies"

    /home/runner/work/courses/courses/packages/database/scripts/databaseFixtures/courseModules.ts:879:11:
      879 β”‚ ] as const satisfies readonly CourseModule[];
          β”‚            ~~~~~~~~~
          β•΅            ;

/home/runner/work/courses/courses/node_modules/tsm/node_modules/esbuild/lib/main.js:1605
  let error = new Error(`${text}${summary}`);
              ^

This is supported in esbuild@^0.15.13


Workaround

Use Yarn/pnpm Resolutions (or npm Overrides) to force the version in package.json:

{
  "resolutions": {
    "**/tsm/esbuild": "0.15.14"
  }
}

`ERR_LOADER_CHAIN_INCOMPLETE` on Node.js 18.6

After updating to Node.js 18.6.0 I start to have an error:

> tsm node_modules/uvu/bin.js . '\.test\.(ts|js)$'

(node:111446) ExperimentalWarning: Custom ESM Loaders is an experimental feature. This feature could change at any time
(Use `node --trace-warnings ...` to show where the warning was created)
(node:111446) DeprecationWarning: Obsolete loader hook(s) supplied and will be ignored: getFormat, transformSource
Error [ERR_LOADER_CHAIN_INCOMPLETE]: "file:///home/ai/Dev/nanostores/node_modules/.pnpm/[email protected]/node_modules/tsm/loader.mjs 'load'" did not call the next hook in its chain and did not explicitly signal a short circuit. If this is intentional, include `shortCircuit: true` in the hook's return.
    at new NodeError (node:internal/errors:387:5)
    at ESMLoader.load (node:internal/modules/esm/loader:624:13)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async ESMLoader.moduleProvider (node:internal/modules/esm/loader:472:11)
    at async link (node:internal/modules/esm/module_job:67:21)

It looks like a conflict with a new loader API from Node.js 18.6

[Feature]: support dynamic import by default

when I use tsm register to transpile module which contains dynamic import, it's broken

  • src/index.ts
async function main(){
  const mod = await import('./lib');
}
main();
  • src/lib.ts
export const answer = 42;

It's broken
image

It's because esbuild will keep dynamic import for high version of node, even you set format=cjs evanw/esbuild#1636
image

when I set target to node12, it works fine now, because it will transform dynamic import to require

  • tsm.js
module.exports = {
  common: {
   target: 'node12'
  }
}

so I think we could set target=node12 by default to support dynamic import by default

Is this repo still maintained? --experimental-loader warning

Hard to use this package due to the constant output of warnings:
(node:11565) ExperimentalWarning: --experimental-loader may be removed in the future; instead use register():
--import 'data:text/javascript,import { register } from "node:module"; import { pathToFileURL } from "node:url"; register("file%3A///usr/local/share/nvm/versions/node/v20.9.0/lib/node_modules/tsm/loader.mjs", pathToFileURL("./"));'
(Use node --trace-warnings ... to show where the warning was created)

Can someone please fix and update the npm published version. It would be very much appreciated.

[Feature]: supports custom mainField

I know it's kind of out of scope, but it would be really nice if tsm could supports custom mainField, then we can do something like this.

  • xxx-lib/package.json
{
  "source": "src/index.ts",
  "main": "dist/index.js",
  "types": "dist/index.d.ts"
}

we could use tsm to load the xxx-lib source file without compile it to js in monorepo.

tsm as shebang should allow scripts to respond to --help and --version

for example given this my-cli.ts script

#!/usr/bin/env tsm

if (process.argv.includes('-h') || process.argv.includes('--help')) {
    console.log('my-cli help')
    process.exit(0)
}

if (process.argv.includes('-v') || process.argv.includes('--version')) {
    console.log(`my-cli version'`)
    process.exit(0)
}

when i run ./my-cli.ts -h or ./my-cli.ts -v, i would expect it to output the help / version of my-cli

however currently the help / version of tsm gets printed instead

in contrast, it behaves as expected when using node in shebang. if changing it to my-cli.js

#!/usr/bin/env node

if (process.argv.includes('-h') || process.argv.includes('--help')) {
    console.log('my-cli help')
    process.exit(0)
}

if (process.argv.includes('-v') || process.argv.includes('--version')) {
    console.log(`my-cli version'`)
    process.exit(0)
}

and run ./my-cli.js -h or ./my-cli.js -v, it correctly output the help / version of my-cli

Resolve remote imports from CDNs?

I use tsm a lot for prototyping ideas without the need to set up a proper project and I love it for that!
As soon as I use dependencies, I'd need to add a package.json and install the depencies as usual.

It would be super cool, if tsm could resolve modules from cdns for that purpose.

Two possible solutions come to my mind:

  • Could tsm support esbuild plugins? This way we could use something like https://esbuild.github.io/plugins/#http-plugin
  • Could this be baked in into tsm? I am not sure what implications that would have for the project and maintenance

Usage with `@babel/register`

Hello,

I'm trying to use @babel/register with tsm like this:

$ node -r tsm -r @babel/register node_modules/uvu/bin.js tests

and I get an error like this:

TypeError [ERR_UNKNOWN_FILE_EXTENSION]: Unknown file extension ".ts" for /home/v1rtl/Coding/x/tests/hooks/useWalletInfo.test.ts
    at new NodeError (node:internal/errors:371:5)
    at Object.file: (node:internal/modules/esm/get_format:72:15)
    at defaultGetFormat (node:internal/modules/esm/get_format:85:38)
    at defaultLoad (node:internal/modules/esm/load:13:42)
    at ESMLoader.load (node:internal/modules/esm/loader:303:26)
    at ESMLoader.moduleProvider (node:internal/modules/esm/loader:230:58)
    at new ModuleJob (node:internal/modules/esm/module_job:63:26)
    at ESMLoader.getModuleJob (node:internal/modules/esm/loader:244:11)
    at async Promise.all (index 0)
    at async ESMLoader.import (node:internal/modules/esm/loader:281:24)

This is my package.json:

{
  "name": "x",
  "private": true,
  "version": "0.0.0",
  "type": "module",
 "devDependencies": {
    "@babel/core": "^7.16.0",
    "@babel/preset-env": "^7.16.0",
    "@babel/preset-react": "^7.16.0",
    "@babel/preset-typescript": "^7.16.0",
    "@babel/register": "^7.16.0",
    "tsm": "^2.1.4",
    "typescript": "~4.4.4",
    "uvu": "^0.5.2"
  }
}

Read compilerOptions from tsconfig in cwd

Hi Luke!

We use tsm with uvu in our new project. I really like how fast our test are with them.

I'm wondering about why tsm doesn't use all the compilerOptions listed in tsconfig.json from the current working directory.

We have "jsx": "react-jsx" option in our tsconfig.json which is not the default and we had to add the following code into tsm.js file to make it work in tests:

const tsConfig = require('./tsconfig.json');

const tsconfigRaw = {
  compilerOptions: tsConfig.compilerOptions,
};

module.exports = {
  common: {
    tsconfigRaw,
  },
};

It works, but it's a bit less convenient then if tsm could automatically read the compiler options from tsconfig.

What do use think about automatically reading tsconfig if it exists in the project?

Thank you!

Support path resolvers from tsconfig

Hi,

in my tsconfig file i have paths set up like this

"compilerOptions": {
		...
		"paths": {
			"$lib/*": ["src/lib/*"]
		}
	},

If I import a module for testing (using loadr, tsm and uvu) the resolution fails as soon as the module/file that I import has a reference to $lib with the following error:
Error [ERR_MODULE_NOT_FOUND]: Cannot find package '$lib' imported from /path/to/lib/utils.ts

Default exports suggested when run via `tsm`

So I'm currently playing around with tsm to get a better grasp of how it works and to create a smaller test runner alike https://github.com/lukeed/uvu but seem to run into an odd issue that the uvu runner doesn't encounter. Whenever I attempt to import files while running my script via tsm ./bin/runner.mjs I run into errors that suggest that I should use default imports.

Runner

export async function runner(suites: string[]) {
	for (const suite of suites) {
		await import(suite)
	}
}

Error

import { format } from 'string-kit';
         ^^^^^^
SyntaxError: Named export 'format' not found. The requested module 'string-kit' is a CommonJS module, which may not support all module.exports as named exports.
CommonJS modules can always be imported via the default export, for example using:

import pkg from 'string-kit';
const { format } = pkg;

    at ModuleJob._instantiate (node:internal/modules/esm/module_job:123:21)
    at async ModuleJob.run (node:internal/modules/esm/module_job:189:5)
    at async Promise.all (index 0)
    at async ESMLoader.import (node:internal/modules/esm/loader:528:24)

Now uvu doesn't run into this issue but I assumed tsm would make sure the .ts files get properly handled. Any pointers at what could cause this are appreciated!

Edit 1: Directly executing via tsm source/hash.test.ts also seems to fail so I assume this isn't related to doing an import via code but a general issue.
Edit 2: I guess it's caused by allowSyntheticDefaultImports which uvu seems to handle fine? Does this need special handling outside of tsm?

Run error under node v14.5.0 version

Hi,
I am using tsm under node v14.5.0 version and the following error is reported

image

So I tried to switch to another node version v16.11.1. As a result, the ts file was successfully executed and the result was printed

image

Compatibility with Yarn 2 (Berry)?

I tried to use the tsm package with command yarn tsm uvu tests and got the following error:

Error: ENOTDIR: not a directory, stat '/Users/user/Developer/project-name/.yarn/cache/tsm-npm-2.2.1-7322a65949-ec9c0c59f0.zip/node_modules/tsm/loader.mjs'
    at statSync (fs.js:1131:3)
    at tryStatSync (internal/modules/esm/resolve.js:109:13)
    at finalizeResolution (internal/modules/esm/resolve.js:301:17)
    at moduleResolve (internal/modules/esm/resolve.js:731:10)
    at Loader.defaultResolve [as _resolve] (internal/modules/esm/resolve.js:842:11)
    at Loader.resolve (internal/modules/esm/loader.js:89:40)
    at Loader.getModuleJob (internal/modules/esm/loader.js:242:28)
    at Loader.import (internal/modules/esm/loader.js:177:28)
    at internal/process/esm_loader.js:57:31
    at initializeLoader (internal/process/esm_loader.js:62:5) {
  errno: -20,
  syscall: 'stat',
  code: 'ENOTDIR',
  path: '/Users/user/Developer/project-name/.yarn/cache/tsm-npm-2.2.1-7322a65949-ec9c0c59f0.zip/node_modules/tsm/loader.mjs'
}

Are directories with index.ts supported?

I have a directory with a few files that I import into an index.ts file. I then import from the directory throughout my code (just feels clean). So something like this in index.ts.

import request1 from './request1';
import request2 from './request2';
import request3 from './request3';

export {request1, request2, request3};

Then used like this in other places in my project: import { request1, request2, request3 } from './requests';

To get this to work in ts-node I need to run like this: node --experimental-specifier-resolution=node --loader ts-node/esm src/main.ts

I believe --experimental-specifier-resolution=node is the key part here. I've been trying something similar with tsm but no luck yet. I've been getting an ERR_MODULE_NOT_FOUND error when trying to import from ./requests.

I'm probably just missing something simple, so my apologies if that's the case! Thanks in advance!

Support native ESM packages

When importing *.js files from packages which have "type": "module" an ERR_REQUIRE_ESM error is thrown:

> node -r tsm index.ts

/home/max/Projects/repro-tsm-native-esm/index.ts:1
import getPort from 'get-port';
                                                                                                                                                                                                                    ^

Error [ERR_REQUIRE_ESM]: require() of ES Module /home/max/Projects/repro-tsm-native-esm/node_modules/.pnpm/[email protected]/node_modules/get-port/index.js from /home/max/Projects/repro-tsm-native-esm/index.ts not supported.
Instead change the require of index.js in /home/max/Projects/repro-tsm-native-esm/index.ts to a dynamic import() which is available in all CommonJS modules.
    at Object.apply (/home/max/Projects/repro-tsm-native-esm/index.ts:1:213)
    at Object.<anonymous> (/home/max/Projects/repro-tsm-native-esm/index.ts:20:34)
    at Module.t._compile (/home/max/Projects/repro-tsm-native-esm/node_modules/.pnpm/[email protected]/node_modules/tsm/require.js:1:935)
    at Object.loader (/home/max/Projects/repro-tsm-native-esm/node_modules/.pnpm/[email protected]/node_modules/tsm/require.js:1:948) {
  code: 'ERR_REQUIRE_ESM'
}

I've created a minimal reproducible case at https://github.com/maxmilton/repro-tsm-native-esm.

This will become increasingly common as more packages migrate to native ESM only.

The same issue popped up on the https://github.com/egoist/esbuild-register project:

and had a fix: egoist/esbuild-register@a540af7.

Seems like a tricky thing to solve without a big hit from extra disk I/O, catching the error like esbuild-register does, or passing through all .js to the esbuild compiler. Catching the error seems like the lesser of the evils but perhaps you'll have a better idea.

Node.js 20 support

Reproduction:

echo "import { test } from 'uvu'; test('one', () => {}); test.run()" > index.test.ts
npm install uvu tsm
npx tsm ./node_modules/.bin/uvu

Node.js 19.9.0 output:

(node:140378) ExperimentalWarning: Custom ESM Loaders is an experimental feature and might change at any time
(Use `node --trace-warnings ...` to show where the warning was created)
(node:140378) DeprecationWarning: Obsolete loader hook(s) supplied and will be ignored: getFormat, transformSource
(node:140378) DeprecationWarning: Obsolete loader hook(s) supplied and will be ignored: getFormat, transformSource
index.test.ts
β€’   (1 / 1)

  Total:     1
  Passed:    1
  Skipped:   0
  Duration:  0.26ms

Node.js 20.0.0 output:

(node:140181) ExperimentalWarning: Custom ESM Loaders is an experimental feature and might change at any time
(Use `node --trace-warnings ...` to show where the warning was created)
(node:140181) ExperimentalWarning: Custom ESM Loaders is an experimental feature and might change at any time
(Use `node --trace-warnings ...` to show where the warning was created)
(node:140181) DeprecationWarning: Obsolete loader hook(s) supplied and will be ignored: getFormat, transformSource

Bug when using tsm with chalk 5.0.0

First of all, thanks for this amazing project!

I noticed that tsm fails to import dependencies from chalk 5, giving the following error:

(node:41021) ExperimentalWarning: --experimental-loader is an experimental feature. This feature could change at any time
(Use `node --trace-warnings ...` to show where the warning was created)
(node:41021) DeprecationWarning: Obsolete loader hook(s) supplied and will be ignored: getFormat, transformSource
file:///Users/leonzalion/projects/tsm-bug/node_modules/.pnpm/[email protected]/node_modules/chalk/source/index.js#supports-color.mts:26
const { stdout: stdoutColor, stderr: stderrColor } = supportsColor;
                ^

TypeError: Cannot destructure property 'stdout' of 'supportsColor' as it is undefined.
    at file:///Users/leonzalion/projects/tsm-bug/node_modules/.pnpm/[email protected]/node_modules/chalk/source/index.js#supports-color.mts:26:17
    at ModuleJob.run (node:internal/modules/esm/module_job:185:25)
    at processTicksAndRejections (node:internal/process/task_queues:96:5)
    at async Promise.all (index 0)
    at async ESMLoader.import (node:internal/modules/esm/loader:281:24)
    at async loadESM (node:internal/process/esm_loader:88:5)
    at async handleMainPromise (node:internal/modules/run_main:65:12)

It seems like the chalk supportsColor import is becoming undefined, and I believe it has something to do with how chalk imports its dependencies:

import ansiStyles from '#ansi-styles';
import supportsColor from '#supports-color';

Here is a GitHub repo that reproduces this error: https://github.com/leonzalion/tsm-bug
Node version: 16.13.2

Let me know if this is a tsm bug and/or if there's a workaround to this issue!

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    πŸ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. πŸ“ŠπŸ“ˆπŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❀️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.