1 of 9

JSON Modules

Update

Myles Borins, Google

Daniel Ehrenberg, Igalia in partnership with Bloomberg

Sven Sauleau, Babel

Daniel Clark, Microsoft

2 of 9

Proposal split

Formerly part of Import Assertions, now a separate stage 2 proposal: https://github.com/tc39/proposal-json-modules

3 of 9

Proposal recap

import json from "./foo.json" assert { type: "json" };

  • If the assertions list includes type: "json", the host must reject the import unless the module is interpreted as a “JSON module”:
    • Module’s contents are parsed as JSON and the resulting object is the module’s default export. The module has no other exports.

4 of 9

Should JSON modules be mutable?

  • Arguments for mutability:
    • More natural to developers who are used to mutability in JS modules
    • If JSON modules are immutable, can’t use them directly in cases where mutability is needed
  • Arguments for immutability:
    • Prevents bugs where unexpected JSON changes from one importer have unintentional effects on other importers
    • If JSON modules are not immutable, importers can only lock them down if they execute first

https://github.com/tc39/proposal-json-modules/issues/1

https://github.com/tc39/proposal-json-modules/issues/3

5 of 9

If immutable, should JSON modules be records/tuples?

  • Immutability could be achieved by running Object.freeze prior to exposing the JSON object, or by exposing the JSON as a Record (https://github.com/tc39/proposal-record-tuple/).
  • Pro of Object.freeze:
    • Existing tooling (and developers) may expect JSON to be an Object
  • Pro of Records/Tuples:
    • Makes it much more obvious that the JSON is locked down.

https://github.com/tc39/proposal-json-modules/issues/2

6 of 9

External positions

7 of 9

HTML Integration

8 of 9

Spec

https://tc39.es/proposal-json-modules

9 of 9

Thoughts/feedback?