lukeed / tsm Goto Github PK
View Code? Open in Web Editor NEWTypeScript Module Loader
License: MIT License
TypeScript Module Loader
License: MIT License
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'
}
git clone [email protected]:nanostores/nanostores.git
git checkout chore/pnpm
pnpm unit
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)
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 π
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'
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.
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
π 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:
plugin
doing required transformationsModule._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?
I just read about differences between tsm
and ts-node
. @lukeed's comment there was very helpful.
Now, I'm curious to know the differences between tsm
and esbuild-runner
.
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?"
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.
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?
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)
What use cases & functionality does tsm
provide that ts-node
does not?
In what cases would it be better to prefer one over the other?
Any plans for watch mode?
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
Use Yarn/pnpm Resolutions (or npm Overrides) to force the version in package.json
:
{
"resolutions": {
"**/tsm/esbuild": "0.15.14"
}
}
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
when I use tsm register to transpile module which contains dynamic import, it's broken
async function main(){
const mod = await import('./lib');
}
main();
export const answer = 42;
It's because esbuild will keep dynamic import for high version of node, even you set format=cjs evanw/esbuild#1636
when I set target to node12, it works fine now, because it will transform dynamic import to require
module.exports = {
common: {
target: 'node12'
}
}
so I think we could set target=node12 by default to support dynamic import by default
The tsm and esmock loaders can be chained together. This example, uses them with node 18s new test runner to run a passing test,
node --loader=tsm --loader=esmock --test *ts
this PR adds a tsm unit-test to esmock
Could this replace ts-jest?
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.
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.
{
"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.
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
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:
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"
}
}
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!
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
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?
Node 16 just landed new loader hooks api. Is tsm compatible with it?
https://github.com/nodejs/node/releases/tag/v16.12.0
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'
}
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!
I love this module for fast development, but the incorrect line numbers in the output is a real issue for me.
Would you consider a PR which adds sourcemap support via something like: https://github.com/evanw/node-source-map-support
...or would the additional dependencies be a total no-go?
When import
ing *.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.
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
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!
A declarative, efficient, and flexible JavaScript library for building user interfaces.
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. πππ
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google β€οΈ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.