Cannot import TypeScript types that have been re-exported

[jagaapple]

Bug report

Describe the bug

As I wrote an issue in @zeit/next-typescript some months ago, Babel does not support to import types or interfaces from re-export files such as index.ts .
On large project, developers create index.js (or index.ts ) to encapsulate the API calls from the web app into a single folder.

@zeit/next-typescript throws warnings when importing re-exported types, but Next.js 9 (using built-in TypeScript transpile system) throws errors in that case. So we cannot develop using re-export files.

To Reproduce

// packages/package-1.ts
export type TypeA = {};

// packages/index.ts
export { TypeA } from "./package-1";

// main.ts
import { TypeA } from "./packages";

Next.js throws errors like the following if the above code is contained in some pages.

Attempted import error: 'TypeA' is not exported from './package-1'.

Expected behavior

Do not raise any errors and warnings.

Additional context

Babel v7 supports to transpile TypeScript files but it is only to remove types from TypeScript files. At this time, the target of import from intersection (index) files will be removed.

// After transpile by Babel...
// ---
// packages/package-1.ts
// export type TypeA = {}; // REMOVED!

// packages/index.ts
export { TypeA } from "./package-1"; // NOT FOUND!

To solve this issue at its foundation, Babel should support re-export files and we should wait to do. However I think that to filter and ignore these errors using regular expressions makes to solve.

[kachkaev]

This is the result of having isolatedModules in the autogenerated tsconfig.json and we can't opt-out of that.

I upgraded one rather small app from Next 8 + @zeit/next-typescript to Next 9 and it was quite painful to refactor all the re-exports. The resulting working code pretty ugly too. Can't imagine upgrading a proper app that has hundreds of export { ... } from "./path/to/file" 😱

[Timer]

This is a Babel bug and I can see how this is frustrating -- we'll want to figure something out for this.

[jeremy-coleman]

although the error isn't clear, its root cause is from exporting a named type, not really from re exporting. this occurs with ts-loader when using transpile only, rollup plugin typescript, etc. (any tool that uses the ts.transpile api).
So, if you have a component file like ..

type P = {
color: 'red'|'green'
}
MyDiv = (props:P) => <div color='red'/>

export {MyDiv, P}

thats not going to work, you have to remove the 'export {MyDiv, P}` and replace with inline exports
like this:

export type P = {
color: 'red'|'green'
}
export MyDiv = (props:P) => <div color='red'/>

also, when you create a barrel file(index.ts), do this:

good
 export * from './MyDiv'
bad
export {MyDiv, P} from './MyDiv'

this codemod will fix most issues
install @codemod/cli and babel-plugin-codemod-named-export-declarations and run this as an npm script

    "trymod": "./node_modules/.bin/codemod -p babel-plugin-codemod-named-export-declarations src/client/**/*.ts"

other options:
2) add ts-loader with enforce pre
3)move all your code out of your next folder and use the typescript compiler to compile it back into where it was. it's pretty hacky but fast AF if you use the tsc incremental option
4)create a workspace with all your types in it

i tried to do some real hackery using gulp to expose the compiled vinyl files over a socket and serve that to next (just to avoid writes to disk). it worked but couldn't get updates to trigger:\

[martpie]

This is a Babel bug

Is there a link to this upstream bug?

edit: found it babel/babel#8361 (comment)

[martpie]

To fix it, just replace export { ... } from "./path/to/file" with the export * from "./path/to/file"

babel/babel#8361 (comment)

[jeremy-coleman]

i put an example repo up here https://github.com/jeremy-coleman/next-tsc-proposal
and a corresponding issue here #7908