Because there is a path here that doesnt impose problems for .js (people could userland "use module" or parse guess) and
-
-
Replying to @bradleymeck @wycats and
The solution doesnt leave tech debt like package json. Doesnt have scaling problems if 3rd mode appears. Is web compatible. And
2 replies 0 retweets 1 like -
"main" -> "module" doesn't leave tech debt more than .js and .mjs. What do you mean?
2 replies 1 retweet 4 likes -
Replying to @wycats @bradleymeck and
That's key. "In defense of JS" was extremely future friendly. Literally "main" -> "module." Was dismissed too quickly imo :(
1 reply 0 retweets 2 likes -
-
Replying to @bradleymeck @wycats and
iirc the other bits were there to support the transition period when projects would have both CJS and ESM modules co-existing.
2 replies 0 retweets 1 like -
Replying to @AdamRackis @wycats and
Kind of, modules.root is an odd duck due to scope creep and keeping file globs forever is odd
1 reply 0 retweets 0 likes -
Replying to @bradleymeck @AdamRackis and
Plus main was never a required field, future still deals with standalone files,etc
1 reply 0 retweets 1 like -
Replying to @bradleymeck @AdamRackis and
Right. The one notable change is making an entry point field mandatory. It's good practice anyway tho.
2 replies 0 retweets 2 likes -
Replying to @wycats @AdamRackis and
Except when you dont have package.json or your tool doesnt deal with package.json yet. Have to add support.
2 replies 0 retweets 1 like
If your tool doesn't support package.json it won't have known about CJS.
-
-
Replying to @wycats @bradleymeck and
Tools that don't know about package.json prolly aren't working too well with Node anyway! :)
1 reply 0 retweets 2 likes -
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.