-
Notifications
You must be signed in to change notification settings - Fork 13.2k
Description
Search Terms
Triple slash, reference, path, lib, library, types, typings, dom
Suggestion
When compiling a .ts file with declaration: true, TSC should emit triple-slash reference paths for all libs consumed by the .ts file.
Problem
Say I publish typings for my package foo to NPM, and foo depends on DOM typings. I then include foo in my project (npm install foo). There are a few things that can happen:
- If
foo's typings include<reference lib="dom" />:
foohas access to DOM- My project has access to DOM types (is this sort of leakage desirable?)
- If my project includes
dom(or uses the same triple-slash directive as in 1):
foohas access to DOM- My project has access to DOM types
- Neither my project nor
fooinclude<reference lib="dom" />:
-
fooerrors wherever it uses DOM types (but I have to inspect node_modules/foo/index.d.ts to see those errors) -
My project treats
foo's DOM types asanys (should this error instrictmode?)// foo.d.ts export function a(): HTMLInputElement // myProject/index.ts import {a} from 'foo' a() // any
Solution
If tsc -d generated triple-slash directives for foo/index.d.ts, we can ensure that we're always in case (1). This is nice because if my project doesn't use dom, I shouldn't have to declare it for the sake of foo like I did in (2); it also avoids the any from (3).
// Before
export function a(): HTMLInputElement
// After
/// <reference lib="dom" />
export function a(): HTMLInputElementAn open question is how strict should TSC be? Ie. If foo uses dom but fails to reference it, should this cause a compile error in my project (and a nice message suggesting I add a reference to dom)?
Checklist
My suggestion meets these guidelines:
- This wouldn't be a breaking change in existing TypeScript / JavaScript code
- This wouldn't change the runtime behavior of existing JavaScript code
- This could be implemented without emitting different JS based on the types of the expressions
- This isn't a runtime feature (e.g. new expression-level syntax)