Skip to content
This repository was archived by the owner on Mar 25, 2026. It is now read-only.
This repository was archived by the owner on Mar 25, 2026. It is now read-only.

Forward compatibility of ignoring unknown keys in the import(…) options bag #121

Description

@fstirlitz

This proposal adds a second… operand(?) to the import(...) expression, an options bag. As I understand it, it is meant to be an extensible mechanism that other language enhancements that modify the importing process may take advantage of.

As currently specified, EvaluateImportCall is defined to ignore the presence of unrecognized keys in the options bag. As far as this proposal is concerned, this is fine, because assertions are meant to be applied opportunistically, and if they pass, they don’t change the semantics of importing; however, there are already proposals in the works building upon this one that do. For example, https://github.com/tc39/proposal-import-reflection may import the module as an entirely different object.

My question is, how is user code to know whether an import option was actually taken into account by the host? How should it prevent a situation where an import call ostensibly returns success, but with the wrong semantics? (e.g. importing a JSON file as if it were an ECMAScript module)

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions