Wesley Wigham
Wesley Wigham
The _usability issue_ is the lack of an API (eg, `require` itself, for simplicity), to _synchronously load a module_. I really hope I can hammer that home to enough people...
Literally, [this](https://github.com/nodejs/modules/issues/389#issuecomment-536061122) - the same file could be interpreted twice, in two different ways (one of which may or may not error due to syntax), which is exactly what we're...
> I disagree with the web disabling TLA in service workers. if TLA randomly doesn't work in certain contexts why would anyone feel motivated to write code with TLA in...
> require could never load esm. nothing was disabled. nothing was lost And service workers have never been able to be modules yet, so nothing was lost with no TLA...
>My concern is specifically when we allow packages to define their own "translators" easily. Even with no first class support, you could write an esm package that compiles some code...
@sheetalkamat was this also fixed by your PR?
`@zustand/vanilla` has incorrect types, again, it only declares types for a cjs entrypoint for everything, and that is the result of that mismatch.
I'm going to need a bigger repro, because given only what's set out here, an `extends` referencing literally `@scope/some-package` with a `tsconfig.json` at `node_modules/@scope/some-package/tsconfig.json`, works just fine, both on `main`...
`yarn` berry patches ts on install, so their patch might not apply correctly to 4.8 or something. Unless you can repro w/o yarn, good chance it's yarn's fault.
@typescript-bot pack this