Description
TypeScript Version: 2.6.1
Intent
To be able to export imports (using allowSyntheticDefaultImports) and not run into the dreaded voldemort cannot be named when importing those exports and consuming them in other modules inside or outside the scope of the project.
Code
Currently, the most intuitive approach exposes the entity but leaves out the type information, resulting in the cannot be named:
import fs from 'fs';
export const { existsSync, readFileSync, writeFileSync } = fs;The TypeScript way of going about this disconnect is to use the export import readFileSync = fs; and do this for each and every member that needs to be exposed both as entity and type:
import fs from 'fs';
export import existsSync = fs.existsSync;
export import readSync = fs.readSync;
export import writeFileSync = fs.writeFileSync;Which is crude when compared to the simplicity of export const {…} = fs; to say the least.
So, here is where it is not clear if this is intentional, a bug, or a future TODO from the past, but as a TypeScript developer one would expect this to be a given valid and supported syntax:
import fs from 'fs';
export import { existsSync, readFileSync, writeFileSync } = fs;Expected behavior:
The export const … is behaving (though not ideal) but on par with TypeScript's conventions since it explicitly exports the entity.
The export import <name> = <namespace>.<name> gladly resolves this disconnect.
But one would expect export import {… <names> } = <namespace> to be valid TypeScript syntax, which behaves like export const {… <names> } = <namespace> but also expose the types.
Actual behavior:
Sadly, while TypeScript can properly handle destructuring in consts, and even transpile those flawlessly to legacy individual var statements, it does not like destructuring in the import counterparts.
edit: simplified code for readability