Skip to content

Declaration files error for function return types #25685

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
robertontiu opened this issue Jul 16, 2018 · 7 comments
Closed

Declaration files error for function return types #25685

robertontiu opened this issue Jul 16, 2018 · 7 comments
Assignees
Labels
Bug A bug in TypeScript Domain: Declaration Emit The issue relates to the emission of d.ts files

Comments

@robertontiu
Copy link

TypeScript Version: 2.9.2

Search Terms: declaration file inline import, declaration files import path error

Code

In src/lib/operators/scalar.ts

export interface Scalar {
	(): string

	value: number
	unit: Unit

	add(value: Scalable): this
	subtract(value: Scalable): this
	multiply(value: Scalable): this
	divide(value: Scalable): this
	get(): string
	toString(): string
}

export function scalar(value: string): Scalar {
	return parseScalar(value)  // returns an object of type scalar
}

In src/settings/spacing.ts

import { scalar } from '../lib/operators/scalar'
const baseSpacing = "14px"

export default {
	get xs() {
		return scalar(baseSpacing).divide(4) // returns an object of type Scalar
	}
})

Expected behavior:
In dist/settings/spacing.d.ts

import {Scalar} from "../lib/operators/scalar"
export default {
	readonly xs: Scalar
}

Actual behavior:
In dist/settings/spacing.d.ts

export default {
	readonly xs: import("src/lib/operators/scalar").Scalar
}

NOTES:

  • Should it import inline? (tslint complains that it shouldn't)
  • The path should be "../lib/operators/scalar"

Local tsconfig.json

{
	"extends": "./../../tsconfig.json",
	"compilerOptions": {
		"baseUrl": "./",
		"paths": {
			"*": ["node_modules/@types/*", "*"]
		},
		"outDir": "./dist",
		"rootDir": "./src",
		"target": "es5",
		"module": "commonjs",
		"moduleResolution": "node",
		"allowSyntheticDefaultImports": true,
		"allowJs": false,
		"declaration": true,
		"jsx": "react",
		"sourceMap": true
	},
	"include": ["./src/**/*"],
	"exclude": [
		"node_modules",
		"src/**/__tests__/",
		"build",
		"dist",
		"scripts",
		"acceptance-tests",
		"webpack",
		"jest",
		"src/setupTests.ts",
		"webpack.config.js"
	]
}

Main tsconfig.json

{
	"compilerOptions": {
		"baseUrl": "",
		"module": "esnext",
		"target": "es5",
		"lib": ["dom", "esnext", "es6"],
		"sourceMap": true,
		"allowJs": true,
		"jsx": "react",
		"moduleResolution": "node",
		"rootDir": "src",
		"forceConsistentCasingInFileNames": true,
		"noImplicitReturns": true,
		"noImplicitThis": true,
		"noImplicitAny": false,
		"strictNullChecks": true,
		"suppressImplicitAnyIndexErrors": true,
		"noUnusedLocals": true,
		"paths": {
			"@libs/components": ["Libs/Components/dist/index.js"]
		}
	}
}
@DanielRosenwasser
Copy link
Member

DanielRosenwasser commented Jul 16, 2018

Can you see if this occurs in the nightlies or 3.0 RC?

Run the following for nightlies.

npm install typescript@next

@mhegazy mhegazy added this to the TypeScript 3.0.1 milestone Jul 16, 2018
@mhegazy mhegazy added Bug A bug in TypeScript Domain: Declaration Emit The issue relates to the emission of d.ts files labels Jul 16, 2018
@weswigham
Copy link
Member

Afaik, you shouldn't set "baseUrl" if you want a relative path generated. Is it set for a reason?

@robertontiu
Copy link
Author

@weswigham I am using baseUrl because it apparently is required to run tsc.
@DanielRosenwasser Same issue with typescript@next.

@weswigham
Copy link
Member

I am using baseUrl because it apparently is required to run tsc

...? How so?

@weswigham
Copy link
Member

Oh, right, we require it be present when using paths... According to our resolution rules, that import path we're generating is valid so long as baseUrl is present, as the baseUrl indicates that the loader would resolve such paths correctly. Considering that you are using node module resolution and not an AMD loader, have you considered not setting either? It looks like your main tsconfig just attempts to reset the values your top-level tsconfig is setting, and that you're not actually using the paths map, really.

@robertontiu
Copy link
Author

@weswigham I'm not entirly sure what you mean but I'll give it a go and post back the result. Thanks

@ronp001
Copy link

ronp001 commented Aug 9, 2018

@weswigham I've encountered what seems to be a different manifestation of the same bug.

Code:

// file: bug_f1.ts
export type type1 = { a: string }
export type type2 = { b: number }
export type combinedType = type1 | type2
//file: bug_f2.ts
import { combinedType } from "./bug_f1"

export function f2(param1: combinedType = { a: "" }, param2: string): combinedType {
  return param1
}
// tsconfig.json
{
  "compilerOptions": {
    "baseUrl": "./",
    "paths": {
      "@src/*": ["src/*"]
    },
    "rootDir": "src",
    "outDir": "dist.tmp",
    "strict": true,
    "declaration": true
  }
}

Expected Behavior:
in bug_f2.d.ts:

import { combinedType } from "./bug_f1";
export declare function f2(param1: combinedType, param2: string): combinedType;

or at least:

import { combinedType } from "./bug_f1";
export declare function f2(param1: import("./bug_f1").type1 | import("./bug_f1").type2 | undefined, param2: string): combinedType;

Actual Behavior:
the import statement in bug_f2.d.ts includes the value from the paths directive:

import { combinedType } from "./bug_f1";
export declare function f2(param1: import("@src/bug_f1").type1 | import("@src/bug_f1").type2 | undefined, param2: string): combinedType;

Changing strict to false causes bug_f2.d.ts to take on the first form (i.e., param1: combinedType).

I saw this happening with 2.9.1, 2.9.2, 3.1.0-dev.20180809

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug A bug in TypeScript Domain: Declaration Emit The issue relates to the emission of d.ts files
Projects
None yet
Development

No branches or pull requests

5 participants