ignoring custom typescript dts type definition files for javascript modules

[restjohn]

TS Template added by @mjbvz

TypeScript Version: 3.9.7

Search Terms

• javascript, js
• d.ts

---

Issue Type: Bug

1. Clone my example repository.
2. Add the repository folder to a VS Code workspace.
3. In a terminal, go to the repository folder and run

npm install
npm run test_with_types

4. The project should build and run some Mocha tests successfully.
5. In VS Code, open the test/legacy.test.ts file.

Expected result

VS Code should not report any errors in test/legacy.test.ts.

Actual result

VS Code applies an error annotation where the file references the legacy.FooOptions type: Namespace '"/<path_omitted>/typescript_custom_dts_issue/src/legacy"' has no exported member 'FooOptions'.ts(2694).

The FooOptions type is declared in the src/legacy.d.ts custom type definition file. The NPM script build:copy_types copies that custom type declaration file to the lib directory, which is the outDir configured in src/tsconfig.json. VS Code appears to ignore that type definition file. Note that importing the legacy module in the test file using ../src/legacy removes the error annotation, but the test generates a runtime error that the module ../src/legacy cannot be found because of course Node cannot load a .ts TypeScript module.

I thought perhaps source maps might be causing VS Code to ignore the definition file in the lib directory, but deleting the source maps and reloading the project did not resolve the issue. Could this have something to do with VS Code attempting to account for the project reference from test/tsconfig.json to src/tsconfig.json?

I have also used the Insider version of VS Code to test and reproduce this issue.

VS Code version: Code 1.47.2 (17299e413d5590b14ab0340ea477cdd86ff13daf, 2020-07-15T18:18:50.054Z)
OS version: Darwin x64 19.5.0

System Info

Item	Value
CPUs	Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz (16 x 2300)
GPU Status	2d_canvas: enabled flash_3d: enabled flash_stage3d: enabled flash_stage3d_baseline: enabled gpu_compositing: enabled metal: disabled_off multiple_raster_threads: enabled_on oop_rasterization: disabled_off protected_video_decode: unavailable_off rasterization: enabled skia_renderer: disabled_off_ok video_decode: enabled viz_display_compositor: enabled_on viz_hit_test_surface_layer: disabled_off_ok webgl: enabled webgl2: enabled
Load (avg)	2, 2, 2
Memory (System)	32.00GB (0.22GB free)
Process Argv
Screen Reader	no
VM	0%

Extensions (47)

Extension	Author (truncated)	Version
vscode-openapi	42C	3.4.0
al-code-outline	and	2.0.4
asciidoctor-vscode	asc	2.8.3
better-toml	bun	0.3.2
solargraph	cas	0.21.1
npm-intellisense	chr	1.3.0
path-intellisense	chr	2.2.1
vscode-eslint	dba	2.1.8
javascript-ejs-support	Dig	1.3.1
docs-yaml	doc	0.2.5
xml	Dot	2.5.0
gitlens	eam	10.2.2
vscode-html-css	ecm	0.2.3
vscode-npm-script	eg2	0.3.12
go	gol	0.15.1
gc-excelviewer	Gra	3.0.38
vscode-nginx-conf-hint	han	0.1.0
vscode-test-explorer	hbe	2.19.1
rest-client	hum	0.24.1
search-node-modules	jas	1.3.0
asciidoctor-vscode	joa	2.8.0
svg	joc	1.3.5
sublime-babel-vscode	jos	0.2.10
vscode-colorize	kam	0.8.17
node-module-intellisense	lei	1.5.0
Kotlin	mat	1.7.1
rainbow-csv	mec	1.7.0
vscode-docker	ms-	1.3.1
python	ms-	2020.7.94776
cpptools	ms-	0.29.0
debugger-for-chrome	msj	4.12.9
gradle-language	nac	0.2.3
node-modules-resolve	nau	1.0.2
vscode-gitignore-generator	pio	1.0.2
vscode-manifest-yaml	Piv	1.19.0
polymer-ide	pol	0.6.0
qub-xml-vscode	qub	1.2.8
vscode-yaml	red	0.9.1
sass-indented	rob	1.5.1
rewrap	stk	1.12.0
code-spell-checker	str	1.9.0
json2yaml	tux	0.2.0
vscode-sourcemaps-navigator	vlk	0.0.3
nodejs-extension-pack	wad	0.1.9
crs-al-language-extension	wal	1.2.4
JavaScriptSnippets	xab	1.8.0
openapi-preview	zoe	1.7.1

[RyanCavanaugh]

This sounds like a configuration error, not a bug. We can investigate if this is reduced to just a set of files that clearly demonstrates a defect

[restjohn]

Please see the example repository I linked in the first reproduction step. That is a pretty minimal project that demonstrates the issue. That also happens to demonstrate this issue: #35296. If this is a configuration issue, I'd love if you can show me where my configuration error is. Note that the project builds and runs just fine from the command line. The problem is that VS Code does not use the definition files in the lib directory and thinks the type the test file references does not exist.

[restjohn]

@RyanCavanaugh what more information do you need for this issue?

[DanielRosenwasser]

@RyanCavanaugh I don't think it is a configuration error, but I don't know the degree to which it's in scope.

The basic scenario is a codebase with project references, where one project dependency has allowJs on, but is internally using a .d.ts to be well-typed. When we go to create a .d.ts file for the dependency project, we'll base it off of the .js file since that's an actual source file.

That means that the depending project sees the TypeScript-generated .d.ts though, which doesn't carry the "intended" type information.

@restjohn, can you confirm that that's what you're seeing?

I guess one workaround is to have your build scripts re-inject the .d.ts file and overwrite things at build time. That means your editing scenario relies on a build step, but it's not the worst, especially for transitionary code.

One thing we could potentially do is copy corresponding .d.ts files if we find them, but the question is sort of "when"? And is it even in the scope of project references?

[restjohn]

Thanks for your response @DanielRosenwasser.

Your description of the symptoms seems correct on the surface, though I reiterate that the project builds from the command line with tsc, while VS Code reports errors in the test files that import src modules with corresponding .d.ts files. VS Code does not see the "intended" types, so marks the code with errors, and intellisense does not work.

If you examine the project in the linked repository, you'll see that the build script does what you say and injects the .d.ts files that type the JavaScript modules from the src directory into the lib directory. The problem is VS Code does not see the lib .d.ts files that the test files import. When I ctrl-click on one of those imported modules from a test file, VS Code jumps to the JavaScript file in the src directory, which might provide some clue as to the cause.

Additionally, you'll see from my comments in the linked related issue that the workaround of copying .d.ts files from src to lib necessitates explicitly compiling src, then copying the .d.ts files to lib, then compiling test, which completely defeats the purpose of using the project reference from test to src. Therefore, I believe part of the solution involves the TypeScript compiler emitting custom DTS files by default rather than generating its own.

[sahendrickson]

Is there any progress on this. I have two files:

• file.d.ts
• file.js

tsc ignores the source file file.d.ts, and creates a new file.d.ts with the contents "export {};"

Subsequently, when ng build runs, it claims that "import * as X from 'file'" doesn't export anything because (I assume) the tsc generated file.d.ts is always empty with "export {};".