Unused @types files installed by node modules pollutes and breaks the main project

[falsandtru]

Even when we don't use it in the main project. For instance, I'm using del package only in the build script file and it is .js file not .ts file.

https://github.com/falsandtru/pjax-api/blob/master/gulpfile.js

But it polluted and broke the main project:

https://travis-ci.org/falsandtru/pjax-api/jobs/525654172#L512

This is caused by sindresorhus/del@0361dcc.

You shouldn't automatically include unused/unimported @types files installed by node modules in the compile targets because they usually won't be used when they are not imported explicitly (regardless of direct or indirect). Or you should provide a way to exclude unexpected @types files by tsconfig.json to avoid this problem as a temporary workaround.

TypeScript Version: 3.4.0-dev.20190425

Search Terms:

Code

You can reproduce this problem also with https://github.com/falsandtru/spica.

1. clone https://github.com/falsandtru/spica
2. checkout v0.0.247.
3. run npm i
4. run npm i del@4.1.1
5. run gulp ts:dist

Expected behavior:

pass

Actual behavior:

TypeScript error: src/throttle.ts(7,5): Error TS2322: Type 'Timeout' is not assignable to type 'number'.
TypeScript error: src/throttle.ts(28,5): Error TS2322: Type 'Timeout' is not assignable to type 'number'.

Playground Link:

Related Issues:

[falsandtru]

Another problem caused by #8836.

[falsandtru]

Namely with client-side projects current TypeScript can't use npm packages bundling their own type definition files which depend on @types/node even when they are not compile targets (e.g. An npm package which is used only in build scripts written in JavaScript such as del).

[falsandtru]

@DanielRosenwasser What is your thought after you deleted your comment? Self-bundled type definition files are going to destroy TypeScript on npm. You have to address this serious design problem ASAP. You can take a temporary measure.

[weswigham]

FYI, If you wanna disable the automatic inclusion of definitions from the project's node_module folder (irrespective of if they're imported) you can just pass a --types argument. Even an empty list will disable the automatic inclusion behavior. Generally we're assuming most projects are assumed to only include a single environement's dependencies in the modules folder, so the auto-include behavior usually picks up globals without need for configuration, so is a better default for most.

[falsandtru]

I can't use that workaround because of depending some @types packages: https://github.com/falsandtru/spica/blob/v0.0.247/package.json#L45-L47. @DanielRosenwasser commented the same workaround but he deleted it. Probably he thought this is not a good workaround because of this problem.

Generally we're assuming most projects are assumed to only include a single environement's dependencies in the modules folder

So you shouldn't use the same folder for @types installed by node modules (especially only for build scripts). To exclude them from default compile targets you should use a different and separated folder.

[weswigham]

That's fine, just use types: ["mocha", "benchmark", "power-assert"]?

[falsandtru]

Of course I know it but such wasteful additional work will be a bad user experience. This problem must be resolved at upstream.

[falsandtru]

I propose that referring package.json like types: "package.json" and making it default.

[DanielRosenwasser]

@weswigham the problem is that the packages include the /// <reference path="types" />, which you can't prevent from loading. So even if you exclude node somehow, Node will always be picked up if it's present.

[falsandtru]

If you pick up @types packages from package.json, you don't refer other unnecessary packages. Thoughts?

[weswigham]

@weswigham the problem is that the packages include the /// , which you can't prevent from loading. So even if you exclude node somehow, Node will always be picked up if it's present

How is that a problem? If a file has a triple slash reference to other types, then it has a hard dependency on them, and needs them present...

[falsandtru]

The problem is separating or filtering, not installing.

[falsandtru]

Can you label this issue "bug" to inform this problem of package developers?

[weswigham]

@falsandtru If anything you should go report a bug on the type definitions that have a /// external reference they don't need.

If you pick up @types packages from package.json, you don't refer other unnecessary packages. Thoughts?

If we ever read a package.json file for configuration (eg, for project references) I'll keep it in mind (but most people list eg, @types/node as a dev dependency so even that is flawed); but right now we require all config be in a tsconfig ❤️