Add support for default imports/exports

[alangpierce]

Simple example:

add.ts

export default function add(a: i32, b: i32): i32 {
  return a + b;
}

main.ts

import add from './add';

export function getValue(): i32 {
  return add(40, 2);
}

Currently both default import and default export syntax are a syntax error. In JS, this is mostly just syntax sugar over a named export called "default", so I think the expected behavior is reasonably straightforward.

I can try taking this on. Some initial thoughts on the steps/details:

• Add support for import {default as foo} from './foo'; and export {foo as default}; so the other syntaxes can be tested individually.
• Extend ImportStatement to have a default-imported name and make it behave like import {default as foo}.
• Add a new CommonFlags.EXPORT_DEFAULT and mark it on export default function and export default class statements. I think these are technically live bindings for the class/function name, if specified, but maybe AssemblyScript should/does disallow overwriting classes and functions anyway?
• Add a new statement type ExportDefaultStatement for export default [expression];. Hopefully this can be implemented similarly to export const.

Does that sound reasonable?

[dcodeIO]

I think implicitly naming default imports default might be sufficient already. Not sure if additional flags or AST nodes are necessary. Should be just the parser that needs to understand a default following an export respectively an import without braces, somewhere in Parser#parseTopLevelStatement maybe.

[alangpierce]

Hmm, I worry about dropping the distinction at the parser level. One concern is just error messages and other tooling-related things; I've definitely seen custom error messages referencing default imports/exports, and I know CoffeeScript tooling is notoriously hard to write because so much information is dropped by the lexer/parser.

Also worth noting that every AST format in https://astexplorer.net/ (as far as I can tell) has a special case for default imports/exports, so it certainly seems common.

A few other cases:

export default function add() {} creates a name add that can be used in the file, so I think the AST needs to both keep the name add and note that it's a default export.

The syntax import a, * as b from 'c'; would be strange to parse and format using ASTBuilder (like in the parser tests) if a turned into {default as a}, since there isn't an import syntax that allows both star and named imports.

export default [expression]; is sort of its own thing in that it doesn't create an assignable binding, although I guess it's similar to a hypothetical export const default = [expression];, but I worry that there are maybe nuanced differences.

[dcodeIO]

Quick update: There is some support for default exports and imports now, internally translating these to become a default member. Combined import syntax like import theDefault, * and import theDefault, { ... } is not yet supported.

[MaxGraey]

Must be supported for quite some time

[MaxGraey]

Partially support. So stay opened

[andrewhassan]

I'm not sure if this ticket is related to the issue I'm having, but exporting the default exports from other files seems like it's not working within AssemblyScript.

In my case, I've created an index.ts file that exports the default exports from the files in its directory. I'm doing this using the following syntax:

export { default as Product } from './Product';

When I try to compile, I get the following error:

ERROR TS1003: Identifier expected.

 export { default as Product } from "./Product";
        ~
 in ~lib/index.ts(1,7)

As far as I can tell, these exports are valid, and the docs don't imply that this shouldn't work.

[MaxGraey]

@dcodeIO It could be also closed I guess

[dcodeIO]

Closing this issue as part of 2020 vacuum as it seems to have been fixed meanwhile, implemented as a default key internally, with the respective syntax mapping to it. If someone knows of or finds additional edge cases, I suggest to make a new issue with updated code samples so we know exactly what to look into.