If Node wants to perfectly implement ES Modules (they don't need to imo) they definitely can't.
-
-
Replying to @AdamRackis @TheLarkInn and
There are minor ambiguities but they're the rub.
2 replies 0 retweets 0 likes -
Replying to @wycats @AdamRackis and
Finding it really hard to let edge case ambiguities warrent an extension change.
2 replies 2 retweets 12 likes -
Replying to @TheLarkInn @wycats and
We are literally able to determine 99.9% of cases accurately and that .01% those users have changed what was really hacky hack code.
2 replies 1 retweet 4 likes -
Replying to @TheLarkInn @wycats and
And there are workarounds for that 0.01% -> add `export default null;` and done.
2 replies 0 retweets 4 likes -
-
-
Replying to @wycats @bradleymeck and
I love seeing some agreement here. Work in out in TC39 please. This is definitely doable without the extension change!
1 reply 0 retweets 0 likes -
Replying to @danbucholtz @bradleymeck and
The problem is the CTC is not at TC39. Just
@bradleymeck.@littlecalculist proposed "use modules" a few meetings ago to close ambiguity.3 replies 0 retweets 3 likes -
Replying to @wycats @danbucholtz and
1: Our position is that systems can either assume module (<script type=module>) or require unambiguous contents.
2 replies 0 retweets 0 likes
2: we still think package.json is good for whole package opt-in (avoids confusing mistakes where the last export is commented out,
-
-
Replying to @wycats @danbucholtz and
3/3: avoids the noise of "use module" everywhere). But unambiguous seems ok as a tie breaker.
0 replies 0 retweets 1 likeThanks. Twitter will use this to make your timeline better. UndoUndo
-
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.