Geoffrey Booth
Geoffrey Booth
It’s certainly much reduced since the initial commit where that warning was added; probably next to nothing for CommonJS files, as that’s what we’ve optimized for. I think it’s probably...
Well that’s great news, I wasn’t expecting that. 1ms for what, a single file? Or an entire app, like if you had a thousand ESM files in a `"type": "module"`...
> I would likely not emit the warning for the top level/entrypoint, but still for everything inside `node_modules`. The problem there is that warning for `node_modules` is really annoying, as...
> I have run a benchmark on one of my “huge” project using ESM on Windows How many ESM files is this, and how many lines of code? I also...
@RomainLanz I just mean count the number of JavaScript files and lines of code in your project. So delete/move away `node_modules` and then run commands to count the number of...
And not to sound like a heretic on performance, but do we generally warn on performance concerns? Like there are all sorts of slow patterns that we could warn users...
> That would be highly complicated to count. As said, it is a real world project that depends a lot on third party libraries (coming from the `node_modules`). If you...
> Shouldn't the proper solution to that problem be including "type" in npm init? https://github.com/nodejs/TSC/issues/1445#issuecomment-1742118965
> Changed it to process.getBuiltinModule() as requested in process: add process.getBuiltinModule(id) Now it mismatches `isBuiltin`. Personally I don't see the confusion between `getIntrinsic` and `getBuiltin`; I think `getBuiltin` is fine,...
> `isBuiltin` is scoped in `node:module`. It is not a function available from the global scope, like `global.process.getBuiltinModule`. Fair enough. I still think we should create an alias on `node:module`...