Home

fromimport

2 min read

Graph View

Inactive
Classification: Syntactic Change
Human Validated: KW
Title: from … import
Authors: Bradley Farias
Never presented; preliminary feedback about syntax cost not being worth the weight
Last Presented: None
Stage Upgrades:
Stage 1: NA Stage 2: NA
Stage 2.7: NA
Stage 3: NA
Stage 4: NA
Last Commit: 2020-04-03
Topics: modules ergonomic
Keywords: module ergonomics
GitHub Link: https://github.com/bmeck/proposal-from-import
GitHub Note Link: None

Proposal Description:

from … import …;

Champion: Bradley Farias (@bmeck)

Stage: 0

Code completion is painful for the current order of import and from. This proposal seeks to add the inverse to make code completion work.

from "foo" import {bar};

Explanation

Status Quo

import /*code completion here*/

Could be a string for the module specier, or the list of imported binding.

  • Tools cannot statically determine the list of possible bindings without the specifier, but it hasn’t been added to the code yet.
  • Tools can create a good completion by inserting the specifier, but doing so means a programmer needs to reposition the cursor to insert binding names which is the common case of imports.
import "foo"/*code completion/programmer moves caret here after typing*/
   // ^ code completion caret needs to be here for binding names

Proposed

from /*code completion here*/

Module specifiers are the only thing that could be here to allow better code completion.

Imports without bindings

import "a";

Just for posterity we can add the from prefixed form, even though it is more verbose:

from "a" import;

Working with other proposals

Module attributes

The position of module attributes would still be at the end.

from "./foo.json" import foo with type="json"

Concerns

  • We would be growing the grammar without any new semantics added to the language.
  • We would need to have different [no LineTerminator here] rules in this form of import.
// allowed currently
import
	* as foo
from
        'foo';

Due to from needing to be a contextual keyword it needs to avoid problems with ASI and would have a grammar like:

from [no LineTerminator here] ModuleSpecifier import ImportClause?

Graph View