The solution doesnt leave tech debt like package json. Doesnt have scaling problems if 3rd mode appears. Is web compatible. And
-
-
"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 -
Replying to @bradleymeck @wycats and
Depends on the tool I guess. If tool needs to know if the JS file is module or not, it should probably support package.json
3 replies 0 retweets 0 likes
More importantly, since this about ambiguity with CJS, if a tool doesn't support package.json, it's not gonna assume CJS
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.