Closed
Description
Restricting Mixing module
and moduleResolution
when one is node*
- Stuff gets weird when you mix
module
andmoduleResolution
. - The first reason to explore this change was we were writing docs that explain what these do.
moduleResolution
is somewhat straightforward; notmodule
.- Conceptually,
moduleResolution
is strictly path lookups,module
decides emit, and is driven by a localpackage.json
, etc.- However we've seen that some of this behavior has leaked.
- So we would like to make the docs clearer, but we need to understand this all better ourselves!
- What happens when you error when they don't match up? Some examples:
- cheerio
- dual CJS/ESM build
- ESM build does
--moduleResolution node16 --module esnext
- CJS does
--moduleResolution node16 --module esnext
- Seems fine, but is a footgun. Assumes everything will be CJS, resolution will go badly.
- Node 16 users are getting the wrong types from this package.
- But the use-case of dual emit is valid and the paths forward today are not great.
- docusaurus
- actually should be using
--moduleResolution bundler
- actually should be using
- cheerio
--module esnext --moduleResolution node16
?- Forcing a dev to say "no the
module
has to benode16
as well has no downsides.
- Forcing a dev to say "no the
- We tried to generalize...but people don't exactly appreciate the degrees of flexibility.
- Can we deprecate?
- Aside - so many of the base
@tsconfig
packages use an invalid mix!--module node16 --moduleResolution node
!!!!!
- Would be great if
package.json
supported multiple values for thetypes
field depending on path/directory. - but by the time Node runtimes broadly support this, it will be a bit. - Feels plausible (desirable) to ban sooner than a long deprecation period.
- Need to update all the
@tsconfig
Naming of Diposable
Disposable
vs.DisposableLike
.- It didn't feel ideal to use
Iterator
for iterator methods, and felt like there was some agreement in committee about placement being off; but ultimately JS can't really support extension methods, and needed an instance and constructor with a prototype so that these Iterator objects can have methods called on them. Disposable
feels... different? It's a one-and-done concept. There's no chaining.- There also already is an instance one can use today -
DisposableStack
. - So there's less likelihood of it becoming a value global.
- No other language with a disposable concept (destructors,
Drop
,IDisposable
, ...) has more than a single method. - Conclusion: stop worrying and love the destructor.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment