4 ms·

They say that it's required for ecsmascript modules that neither import nor export (for instance, modules that place things in the global namespace), but I woul

They say that it's required for ecsmascript modules that neither import nor export (for instance, modules that place things in the global namespace), but I would argue those are mostly shims for a pre-moudule era and they should just be `required()`. Or perhaps they could use some special comment at the top to let Node know it should be treated as a module even though it doesn't look like one. Otherwise, just work down the `import` tree from index.js and anything that is imported is a escmascript module, everything that is required() isn't. Of course, this is just an armchair quarterback opinion, but I'm curious to know why that approach wouldn't work.

s_tec 8y ago
Exactly! You have to know whether something is a script or a module before you can parse it, but with this plan, that's always clear from the context. This is exactly how browsers do it, by the way. If you `import` something, is a module, period. The `<script>` tag is the only place that supports both, so they use a `module="true"` flag to indicate which is which.
- deleted 8y ago
  [deleted]
- chrismorgan 8y ago
  Small correction: it’s <script type="module">, as distinct from <script> or <script type="text/javascript">.
- jkrems 8y ago
  > This is exactly how browsers do it, by the way. If you `import` something, is a module, period. The `<script>` tag is the only place that supports both, so they use a `module="true"` flag to indicate which is which. This is not entirely true. If you import something and it's served with a content type associated with JavaScript modules, then it's interpreted as a JS module. But if they are served with a wasm content-type, they may in the future interpreted as wasm modules. In node there's the additional content-type of "CommonJS file" which has to be handled somehow as well. Non-module script tags aren't really relevant because node itself never supported scripts (at least not what the browser and the ECMA standard calls scripts).
snek 8y ago
>I would argue those are mostly shims for a pre-moudule era and they should just be `required()` Modules are always strict, so loading something intended to be a module as commonjs could break the code within, which expects strict mode. Consider the following source text: `delete Object.freeze({ a: 1 }).a` It will return `false` in sloppy mode, and throw in strict mode. So loaded as commonjs, it will do nothing, and as a module it will be an uncaught exception. >perhaps they could use some special comment at the top to let Node know it should be treated as a module even though it doesn't look like one. This was discussed, but one of our goals is to be able to know what type of file something is before reading its contents. our ESM implementation, unlike CJS, doesn't assume that everything it uses comes from the local fs.
- s_tec 8y ago
  Right. In other words, if you `import` a file with that line, it should crash. If you `require` the file, it will do nothing. The context can determine the file type unambiguously, and you don't need an extension. > This was discussed, but one of our goals is to be able to know what type of file something is before reading its contents. The file extension came from an earlier plan where `require` and `import` could be used on both types of Javascript. Now that the plan uses `import` only for modules and `require` only for scripts, you can get rid of the extension. > our ESM implementation, unlike CJS, doesn't assume that everything it uses comes from the local fs. Node is `import`ing from HTTP, it can use content-type like browsers do. This is only a problem for local file systems, which don't have content-type. For that, you can just assume everything is a module. If people need to load CJS, they can use `require` (as the proposal above already says). Bare import specifiers like `import { foo } from 'lodash'` aren't URI's, so you don't need to maintain compatibility with the browser. For this, you can just use the existing [package.json/module](https://github.com/rollup/rollup/wiki/pkg.module https://github.com/rollup/rollup/wiki/pkg.module) field to determine whether to enter the ESM world or the CJS world. I know Node rejected the package.json solution back when they were trying to make `import` and `require` interchangeable, but now that they aren't, I think the original performance worries should no longer apply.
  - snek 8y ago

s_tec 8y ago

Exactly! You have to know whether something is a script or a module before you can parse it, but with this plan, that's always clear from the context. This is exactly how browsers do it, by the way. If you `import` something, is a module, period. The `<script>` tag is the only place that supports both, so they use a `module="true"` flag to indicate which is which.

deleted 8y ago
[deleted]
chrismorgan 8y ago
Small correction: it’s <script type="module">, as distinct from <script> or <script type="text/javascript">.
jkrems 8y ago
> This is exactly how browsers do it, by the way. If you `import` something, is a module, period. The `<script>` tag is the only place that supports both, so they use a `module="true"` flag to indicate which is which. This is not entirely true. If you import something and it's served with a content type associated with JavaScript modules, then it's interpreted as a JS module. But if they are served with a wasm content-type, they may in the future interpreted as wasm modules. In node there's the additional content-type of "CommonJS file" which has to be handled somehow as well. Non-module script tags aren't really relevant because node itself never supported scripts (at least not what the browser and the ECMA standard calls scripts).

snek 8y ago

>I would argue those are mostly shims for a pre-moudule era and they should just be `required()` Modules are always strict, so loading something intended to be a module as commonjs could break the code within, which expects strict mode. Consider the following source text: `delete Object.freeze({ a: 1 }).a` It will return `false` in sloppy mode, and throw in strict mode. So loaded as commonjs, it will do nothing, and as a module it will be an uncaught exception. >perhaps they could use some special comment at the top to let Node know it should be treated as a module even though it doesn't look like one. This was discussed, but one of our goals is to be able to know what type of file something is before reading its contents. our ESM implementation, unlike CJS, doesn't assume that everything it uses comes from the local fs.

s_tec 8y ago
Right. In other words, if you `import` a file with that line, it should crash. If you `require` the file, it will do nothing. The context can determine the file type unambiguously, and you don't need an extension. > This was discussed, but one of our goals is to be able to know what type of file something is before reading its contents. The file extension came from an earlier plan where `require` and `import` could be used on both types of Javascript. Now that the plan uses `import` only for modules and `require` only for scripts, you can get rid of the extension. > our ESM implementation, unlike CJS, doesn't assume that everything it uses comes from the local fs. Node is `import`ing from HTTP, it can use content-type like browsers do. This is only a problem for local file systems, which don't have content-type. For that, you can just assume everything is a module. If people need to load CJS, they can use `require` (as the proposal above already says). Bare import specifiers like `import { foo } from 'lodash'` aren't URI's, so you don't need to maintain compatibility with the browser. For this, you can just use the existing [package.json/module](https://github.com/rollup/rollup/wiki/pkg.module https://github.com/rollup/rollup/wiki/pkg.module) field to determine whether to enter the ESM world or the CJS world. I know Node rejected the package.json solution back when they were trying to make `import` and `require` interchangeable, but now that they aren't, I think the original performance worries should no longer apply.
- snek 8y ago