Don't include full paths in module names in error messages

[Svish]

TypeScript Version: 4.0.5 (also tested with typescript@next)

Search Terms: namespace has no exported member error

Description

Currently certain error messages shows full file paths. For example:

Namespace '"y:/projects/opf/portal/OPF.Portal.Web/Content/Scripts/DinSide/App/Store/index"' has no exported member 'All'. ts(2694)

Could not find a declaration file for module 'shortid'. 'y:/projects/opf/portal/OPF.Portal.Web/node_modules/shortid/index.js' implicitly has an 'any' type. Try npm install @types/shortid if it exists or add a new declaration (.d.ts) file containing declare module 'shortid'; ts(7016)

Our project was started without strict: true (and few @typescript-eslint rules), so the code base includes several thousand errors. To be able to gradually fix them, we have started to use betterer, which includes committing a snapshot of all the current errors. Snapshot is then used to report report when we fix errors, and fail our build if we add new errors. But because of certain Typescript errors using full file paths, we're getting unnecessary diffs in this snapshot.

Would it be possible to use file paths relative to the project/tsconfig.json root in the error messages instead?

So, with tsconfig.json in y:/projects/opf/portal/OPF.Portal.Web/, the error message would instead be:

Namespace '"Content/Scripts/DinSide/App/Store/index"' has no exported member 'All'. ts(2694)

An alternative solution could be to change betterer instead, make it auto-replace file paths with relative paths, or something like that. But figured I could at least ask her, especially since it could maybe be an issue for other tools as well.

Related Issues: Couldn't find any

[RyanCavanaugh]

This is already the case, at least some of the time. Can you show how to reproduce the problem?

D:\Throwaway\tttt>tsc
a.ts:1:7 - error TS2322: Type 'number' is not assignable to type 'string'.

1 const a: string = 0;
        ~

b/c.ts:1:7 - error TS2322: Type 'string' is not assignable to type 'number'.

1 const n: number = "";
        ~

Found 2 errors.

[Svish]

Yeah, but I don't know how to do it it in e.g. the typescript playground, sorry 😕

Namespace '...' has no exported member '...'

// types.ts
export interface Foo { }

// file.ts
import * as Types from './types';

export interface File {
  foo: Types.Foo;
  bar: Types.Bar; // <-- Should give the "Namespace has no exported member" error with full file path
}

Could not find a declaration file for module '...'. '...' implicitly has an 'any' type.

// file.ts
import shortid from 'shortid'; // <-- Any dependency missing type declarations gives error with full file path

[Svish]

Found another error showing full paths, but not sure how to reproduce it because I don't quite understand what's going on in the code that produces it:

Element implicitly has an 'any' type because expression of type 'string' can't be used to index type 'typeof import("y:/projects/opf/portal/OPF.Portal.Web/Content/Scripts/ts/shared/util/validation/index")'.
  No index signature with a parameter of type 'string' was found on type 'typeof import("y:/projects/opf/portal/OPF.Portal.Web/Content/Scripts/ts/shared/util/validation/index")'. ts(7053)

[Svish]

Actually, I think it might be the same issue as the namespace one, except for other code:

// functions.ts
export const foo = () => {}

// file.ts
import * as functions from './functions.ts';

functions['bar']; // <-- If using a string, or a key that does not exist, you should get the error with two full file paths

[RyanCavanaugh]

👍

[Svish]

So to sum up, there are 3 errors (that I know of) which include full paths:

• ts(7016) - Missing declaration file
• ts(7053) - Element implicitly have 'any' type / No index signature
• ts(2694) - Could not find declaration file for module

[RyanCavanaugh]

It's any time we reference the name of a module, which are internally represented by their full disk path. During error message construction we should convert them back to tsconfig-relative paths