ESM modules and json importing [feature request]

[damianobarbati]

Will it be possible in the future to import .json files as we used to required .json files?

import pkg from './package'
import { name, version } from './package'

[targos]

The current ESM implementation already allows to import a JSON as default (first line).
I suppose we could add named imports, if it's something that users ask for.

/cc @nodejs/modules

[devsnek]

named exports from json doesn't make a whole lot of sense to me. named imports are not and shouldn't be used in place of destructuring.

[bmeck]

I have some concerns with JSON imports that I can list here:

1. Imported names (and properties of the Namespace Object) must be valid JS identifiers, things like en-US are invalid, so you need to still use the default.
2. Primitives don't really make sense for named imports. However, string length is potentially useful??
3. Arrays could only read the length which we cannot make a live binding (unless we use Proxies).
4. If we want the bindings to be live since we need to always export a default (and therefore allow mutation of the original JSON) per number 1 we need to wrap it in a proxy and not track additional properties, just like esm: provide named exports for builtin libs #20403 does.
5. Since number 1 is required we cannot import a default property from JSON.

[ljharb]

a json file should only have a default export; named imports are decidedly NOT destructuring, and allowing this would spread that confusion.

[jdalton]

Named exports work for the cases they do and don't for the cases they don't. Users don't care about the cases named exports don't work since they can use alternative import forms to grab them. It's a convenience thing. JSON is just another module.exports value. This will shake out naturally if CJS named exports support expands, from just builtin modules, to a wider scope.

[bmeck]

@jdalton I don't understand the major wins vs just using destructuring which is also static so tree shaking isn't a problem. The edge cases are weird. Adding weirdness for the sake of convenience I think needs to have a more compelling reason than what exists in this thread currently to me personally.

[jdalton]

JSON support isn't something that has to be explicitly expanded or deliberated on. It shakes out naturally, with no extra work, with wider CJS named exports support as seen with Babel and esm packages.

[ljharb]

That it’s no extra work doesn’t mean it’s a good idea. Even if named exports from CJS are able to become a thing, i don’t think that should be made to apply to json imports.

[jdalton]

Named exports for CJS is an interop enhancement. As such it doesn't seem like the place to start green-fielding and diminishing value.

[bmeck]

@jdalton I don't see it as no extra work / naturally shaking out from how JSON works? I'm not sure I understand how this affects my concerns above.

[jdalton]

In CJS Node supports loading .json files from require. It parses the JSON and bolts the value on to a module.exports. So it's just another module.exports value (nothing special about it).

CJS named exports work in the cases they can work. It's an interop enhancement which means, yes, some cases like property names that can't be translated into identifiers won't be supported as a named export and that's fine. That isn't something supported by Babel or others anyways.

[bmeck]

@jdalton we are not talking about CJS named exports here. I disagree on your course of discussion unless we tie these features together.

[devsnek]

with cjs, everything is an object

with esm, everything is well-known values

json is, by definition, a representation of an object.

saying that "because we do it in cjs we should do it in esm" is in my opinion a very silly stance because they are inherently different.