As a developer, you need to know which scripts are modules and which are regular scripts, because they behave differently. It makes sense to encode that distinction in the file extension somehow, IMHO.
-
-
Replying to @mathias
I know, I'm just sad the "has import/export? then ESM" idea fell through in the end
1 reply 0 retweets 11 likes -
I think the goal there was avoiding having to parse the whole file before knowing how to do the module loading.
3 replies 0 retweets 6 likes -
Replying to @jakehamiltondev @mathias
import/export are static statements though
1 reply 0 retweets 5 likes -
I'm not sure I understand what you mean by that. How would you know to use cjs or es modules without parsing the file?
1 reply 0 retweets 0 likes -
Parse until the first import or export. It's really not that hard.
2 replies 0 retweets 6 likes -
Not having to parse at all seems simpler, no?
3 replies 0 retweets 14 likes -
This is not simpler no. File extensions are a terrible way to detect the type of anything.
1 reply 0 retweets 8 likes -
Why? Node.js has been doing it from the start. Compare e.g. require('a.json') vs. require('b.js').
2 replies 0 retweets 0 likes -
You've been advocating explicit extensions lately, but this is not how things have traditionally been. What happens with inferred paths, e.g `index.js` or whatever `package.main` says?
1 reply 0 retweets 2 likes
Not just lately :) Explicit > implicit, IMHO. `package.main` is different; native modules don’t yet support bare specifiers. We’re working on making that happen.
-
-
I mean more like import an index file by referencing a directory
2 replies 0 retweets 1 like -
explicit > implicit
2 replies 0 retweets 1 like - 6 more replies
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.
JavaScript, HTML, CSS, HTTP, performance, security, Bash, Unicode, i18n, macOS.