Feature: Import JSON without needing asynchronous syntax

[GeoffreyBooth]

Updated feature request description:

Imagine code like this in current Node:

const packageJson = JSON.parse(fs.readFileSync('./package.json'));
console.log(`Running version ${packageJson.version}`);

This can also be written as:

const packageJson = require('./package.json');
console.log(`Running version ${packageJson.version}`);

Both of these examples are written without asynchronous syntax on the user’s part: there are no callbacks, no promises, no await. Perhaps Node is doing asynchronous stuff behind the scenes, but the user is unaware of it. require appears to be as synchronous as readFileSync.

This feature request is that a user’s code to import JSON files via ESM should be like these examples: no callbacks, no promises, no await. This feature request doesn’t concern Node’s implementation under the hood, and whether it is synchronous or asynchronous; the request is only that the user’s code be able to be written in a synchronous style.

Use case 48. Part of #100.

---

Original feature request description:

ESM imports of JSON can be written in a synchronous style:

import { version } from './package.json';
console.log(`Running version ${version}`);

The point of this feature is that users can use the same synchronous style of coding (in the vein of fs.readFileSync as opposed to callback- or promise-based alternatives) when the import is of JSON. Or put another way, users aren’t required to use await or promises or other asynchronous constructs in code in order to import JSON.

Use case 48. Part of #100.

[devsnek]

i don't understand this at all. assuming the "synchronous" part is that its being statically imported, it would be better to then just say that, as there's nothing inherently (a)synchronous about static imports.

if this isn't referring to the static import then it will definitely need to be clarified further.

[GeoffreyBooth]

It’s just that the import doesn’t return a promise, regardless of the module type of what is to be imported. I can import something and then immediately use it in the next line:

import { keys } from 'underscore'; // CommonJS package
const dateKeys = keys(Date);

[devsnek]

so like i said above, maybe this should be rephrased?

[GeoffreyBooth]

What would you have it say? I’m not sure I understand.

The only reason this feature is here is because there was some discussion of handling CommonJS imports via async import(). This feature is a request that the regular ES2015 import statement be usable for CommonJS.

[devsnek]

anything that can be statically imported can be dynamically imported and vice-versa. there is no difference in how they are handled.

neither the use of dynamic or static import informs whether the user agent is actually processing import requests synchronously or asynchronously.

[devsnek]

poorly phrased dupe of #100

[GeoffreyBooth]

Let's not close features without consensus, if you don't mind? As I wrote at the top, this is part of #100. That one is so big that I thought it would be best to discuss its parts in separate threads.

[devsnek]

this issue is literally meaningless. all it says once you degarble it is "allow us to import cjs" which already is what #100 is. specifically stating that you want static imports to work is pointless, and saying "synchronous" is at best a misunderstanding and at worst intentionally misleading.

[benjamingr]

@devsnek I read this issue as automatically creating named exports from JSON files.

• We can do this without supporting named imports for cjs
• JSON is statically analyzable unlike regular CJS, so we can support this even without late bindings.

[benjamingr]

That said, I'm having a very hard time following all these issues.

[GeoffreyBooth]

this issue is literally meaningless . . . at best a misunderstanding and at worst intentionally misleading.

I would appreciate a more collaborative tone here.

This was an item of its own on the features document. It also seemed to me like a subset of #100, which is also its own item on the features document, but because that one is so huge I’m proposing we split that one up into smaller chunks and then close #100. In the interest of not making unilateral decisions, though, I wanted to leave it to the group to find consensus on how these should be organized. Perhaps that should be a topic for the next meeting.

@benjamingr You are correct, but don’t forget that the feature included CommonJS, not just JSON. I think it’s as simple as it seems, that with regards to importing non-ESM modules, users are allowed to code in a synchronous style (in the vein of fs.readFileSync as opposed to fs.readFile with a callback, or a promise-based version). That’s really it. It’s a cousin of #87, of saying that users can continue using the syntax they’re used to regardless of whether the member to be imported is ESM or CommonJS. I’ve edited the original post to add more detail, please let me know if it’s still unclear.

[benjamingr]

@benjamingr You are correct, but don’t forget that the feature included CommonJS, not just JSON

Then is it possible to open a separate issue for JSON?