Use import types to refer to declarations in declaration emit

[weswigham]

With this change, we consider all exported members as 'visible' for declaration emit, and then use import types to reference them. This means, eg, this:

// @filename: file1.ts
export class Foo {}
// @filename: file2.ts
export function foo(): import("./file1").Foo {
    return null as any;
}
// @filename: file3.ts
import {foo} from "./file2";
export function bar() {
    return foo();
}

emits these declarations:

// @filename: file1.d.ts
export class Foo {}
// @filename: file2.d.ts
export function foo(): import("./file1").Foo;
// @filename: file3.d.ts
export function bar(): import("./file1").Foo;

Small todo/discussion point: Based on discussions we've had internally, if there are other import statements preserved in the declaration emit (or maybe all the time? IDK - I personally prefer the import types in many cases), we should coalesce repeated imports into a single synthetic import statement - this is just a style adjustment, as it would just cut down on repeated import types in favor of import x = require("") declarations. However, from a "makes the declaration authoring experience better" PoV, this is already usable as is. It'd be nice to know what people's preferences are here, though.

Fixes #9944
Invalidates #22132

[mhegazy]

there are a set of error messages that should be unused now, e.g. * from external module blah and can not be named errors, we should remove these..

[weswigham]

Technically those are still possible:

// file1:
export function f() {
  interface Local { x: any }
  const y: Local = null as any;
  return y;
}
// file2:
import { f } from "./file1"
export default f();

[mhegazy]

i see..

[RomanHotsiy]

Thanks, @weswigham to finally fixing this issue 🎉 !
Is there any chance it can land into the upcoming 2.9 release?

[simonbuchan]

Don't think I didn't see that branch name...

[n8agrin]

I may not be understanding a subtlety of what this PR is attempting to solve, but I do think it was supposed to solve a problem I'm still running into when building React components in Typescript, specifically the TS4023 error Exported variable 'Button' has or is using name 'React.ClassAttributes' from external module "<PATH>/node_modules/@types/react/index" but cannot be named. This is with the following package.json, tsconfig.json file and from running tsc:

package.json

 ...
  "devDependencies": {
    "@babel/cli": "7.0.0-beta.44",
    "@babel/core": "7.0.0-beta.44",
    "@babel/plugin-proposal-class-properties": "7.0.0-beta.44",
    "@babel/plugin-proposal-object-rest-spread": "7.0.0-beta.44",
    "@babel/plugin-transform-runtime": "7.0.0-beta.44",
    "@babel/preset-env": "7.0.0-beta.44",
    "@babel/preset-react": "7.0.0-beta.44",
    "@babel/preset-typescript": "7.0.0-beta.44",
    "@types/classnames": "2.2.3",
    "@types/jest": "22.2.2",
    "@types/react": "16.4.2",
    "@types/react-dom": "16.0.6",
    "@types/react-intl": "2.3.5",
    "@types/react-test-renderer": "16.0.1",
    "babel-jest": "22.4.3",
    "babel-plugin-looker-inline-sass": "1.0.4",
    "babel-preset-env": "1.6.1",
    "babel-preset-react": "6.24.1",
    "css-loader": "0.28.11",
    "identity-obj-proxy": "3.0.0",
    "jest": "22.4.3",
    "node-sass": "4.8.3",
    "prop-types": "15.6.1",
    "react-docgen-typescript": "1.2.6",
    "react-styleguidist": "7.0.5",
    "react-test-renderer": "16.3.1",
    "regenerator-runtime": "0.11.1",
    "request": "2.85.0",
    "rimraf": "2.6.2",
    "sass-loader": "6.0.7",
    "styled-components": "3.3.3",
    "stylish": "1.0.0",
    "ts-jest": "22.4.2",
    "ts-loader": "3.5.0",
    "tslint": "5.10.0",
    "tslint-config-standard": "7.1.0",
    "tslint-react": "3.6.0",
    "typescript": "2.9.2",
    "typings-for-css-modules-loader": "1.7.0",
    "webpack": "3.5.0"
  },
  "dependencies": {
    "@babel/runtime": "7.0.0-beta.44",
    "chroma-js": "^1.3.7",
    "classnames": "2.2.5",
    "insert-css": "2.0.0",
    "polished": "1.9.3",
    "react": "16.4.1",
    "react-dom": "16.4.1",
    "svg-inline-loader": "^0.8.0"
  },
  "peerDependencies": {
    "styled-components": "3.3.3"
  }
 ...

tsconfig.json

{
  "compilerOptions": {
    "allowSyntheticDefaultImports": true,
    "declaration": true,
    "jsx": "react",
    "noFallthroughCasesInSwitch": true,
    "noImplicitReturns": true,
    "noUnusedParameters": true,
    "outDir": "dist",
    "plugins": [
      {
        "name": "tslint-language-service",
        "alwaysShowRuleFailuresAsWarnings": true
      }
    ],
    "skipLibCheck": true,
    "sourceMap": true,
    "strict": true,
    "module": "commonjs",
    "target": "es6"
  },
  "include": [
    "./src/**/*.ts",
    "./src/**/*.tsx",
    "./config/typescript/**/*"
  ],
  "exclude": [
    "./src/**/*.test.ts",
    "./src/**/*.test.tsx",
  ]
}

I'm trying to create a library of React components for other Typescript projects to consume so I must generate declaration files. A simple repro of this error should occur when trying to compile this React component created by StyledComponents:

import styled from 'styled-components'
export interface ButtonProps {}
export const Button = styled<ButtonProps, 'button'>('button')``

A "fix" for the compiler error which also makes tslint and the tsconfig noUnusedLocals setting happy is:

import styled, {StyledComponentClass} from 'styled-components'
import * as React from 'react
export { React, StyledComponentClass }

export interface ButtonProps {}
export const Button = styled<ButtonProps, 'button'>('button')``

Adding the import * as React from 'react' and import { StyledComponentClass} from 'styled-components' statements is non-obvious. Confusingly, tsc can compile the code to working Javascript fine without those imports. Omitting them only produces an error when declaration files are being emitted, when the library is being packaged for distribution. This dichotomy makes this error extremely confusing and non-obvious.

Is there something I'm missing here? StyleComponents itself imports the React types. I am surprised the Typescript compiler can't walk the dependency tree and extract the exported types it needs to build declaration files.

[weswigham]

@n8agrin You're probably looking at an instance of #24666.

[n8agrin]

@weswigham 👍 thank you for the response and your work!