Suggestion: add excludeTypeRoots to tsconfig #18588

k8w · 2017-09-20T06:32:53Z

TypeScript Version: 2.4.0 / nightly (2.5.0-dev.201xxxxx)
2.5.2

It's a old issue that haven't resolve yet.

#17242 #17042

Resubmit this for old ones are closed.

Case

Used many declaration in node_modules/@types
@types/node bring some compile error (it is a frontend project, but @types/node is a dependency of other package)
So it need to disable @types/node, while other

Suggestion

Support excludeTypeRoots in tsconfig.json.
excludeTypeRoots have higher prioiry than typeRoots

The text was updated successfully, but these errors were encountered:

mhegazy · 2017-09-21T22:49:54Z

So far we have not got this request for many users. with types specifying what to include and typeRoots to specify the location to look for types it seems possible to address most scenarios. adding yet another include/exclude pattern for types is not attractive.

k8w · 2017-09-22T02:25:10Z

This issue is mainly happened in those full-stack library. (Both support Node and browser).

Some of this library depends on @types/node, such as Protobuf.js.

And this would lead to some error.
etc. return type of setTimeout is different when there is @types/node.

mhegazy · 2017-09-22T23:22:28Z

My recomendation here is to set types in your tsconfig.json all the time. I have personally found it to be more predictable this way while working on multi-project repos.

k8w · 2017-09-25T06:20:54Z

@mhegazy
It can't resolve the problem, you just try this:

npm install @types/protobufjs

Code

let shouldBeNumber = setTimeout(() => { }, 0);
shouldBeNumber = 123;

If @types/node is used, this will get a compile error, otherwise it will compile successfully.

Setting types to ["protobufjs"] (withoutnode) is useless.
Because node is a dependency of @types/protobufjs, that's why I say it need a way to exclude.

mhegazy · 2017-09-25T17:25:11Z

I miss understood the situation then. this seems like a definition issue. include/exclude starts the process. but once there is an import or /// <reference types=".." /> the compiler will suck in the additional definition files. that is the same way include / exclude work today for files as well.

The definition file should not have a dependency on node if it does not need it.

k8w · 2017-11-09T07:03:41Z

The definition file should not have a dependency on node if it does not need it.

But actually, there is already many frontend packages depend on @types/node, such as @types/react-dom @types/protobufjs and so on...

mhegazy · 2017-11-09T18:06:10Z

But actually, there is already many frontend packages depend on

These are definition bugs that need to be fixed i would say.

k8w · 2018-01-04T03:23:35Z

Actually many definition have bugs.
It impossible to make every developer submit a PR and wait author to update them.
So it is very necessary to have a way to disable those definition with bugs.

Actually many definition from JavaScript project would have this problem.
Indeed so many... You can find many issue in DefinitelyTyped everyday. such as:

Of course I can write my own definition in typings, but the problem is sometimes it would be conflict with the original one. That's why I need a option to exclude them.

k8w · 2018-03-08T10:12:02Z

Still have this problem, anyone have good way to resolve ?
So many library have this problem, even @types/react-dom

fqborges · 2018-10-22T22:11:29Z

Just to up this, it is giving me headaches.

Venryx · 2018-10-23T06:56:59Z

Have the same problem with [email protected]. It depends on dnd-core, which depends on @types/node, which globally declares the require function, which causes a duplicate require declaration error.

I've tried using the paths property to redirect references to @types/node to an empty file, but it appears to have no effect:

"paths": {
  "../node_modules/@types/node": ["Frame/NPMOverrides/node.d.ts"],
  "node_modules/@types/node": ["Frame/NPMOverrides/node.d.ts"],
  "@types/node": ["Frame/NPMOverrides/node.d.ts"],
  "node": ["Frame/NPMOverrides/node.d.ts"],
}

EDIT: Have worked around the issue for now by setting compilerOptions.skipLibCheck to true in my tsconfig.ts file. Not ideal, but at least the compile error doesn't show up now.

fqborges · 2018-10-23T13:30:12Z

It can be managed using the postinstall workaround mentioned on another thread. Recommend using shx package for multiplatform support.

"postinstall": "shx rm -rf node_modules/@types/node && echo 'workaround for libs importing @types/node on browser environment'"

EDIT:
from: #18588 (comment)
a better workaround than running rm -rf on postinstall: DefinitelyTyped/DefinitelyTyped#21310 (comment)

garrettmaring · 2018-11-03T18:25:28Z

This should be supported.

OliverJAsh · 2018-11-05T16:46:54Z

My recomendation here is to set types in your tsconfig.json all the time

This recommendation isn't ideal for my use case, which is: I have a base tsconfig.json that defines types, and I want to extend it (using extends).

If I specify types in the extension config, it will override the types from the extended config (perhaps it could merge?). This unfortunately means I'm left with no option but to duplicate the list in both TS configs, which is a bit of a maintenance burden.

wallzero · 2019-01-27T10:10:37Z

Unless I have overlooked something, this would also be handy in lerna projects. I have some packages that don't require fancy libs and some that do. However, since the dependencies are hoisted, typescript scans the definitions from all the packages and determines that even the simple ones need esnext.asynciterable for example.

I can either prevent certain @types packages from being hoisted, or I can explicitly list the types in the simple packages tsconfig.json - but a blacklist option would be preferred.

AndrewJDR · 2019-02-19T12:51:27Z

It can be managed using the postinstall workaround mentioned on another thread. Recommend using shx package for multiplatform support.
"postinstall": "shx rm -rf node_modules/@types/node && echo 'workaround for libs importing @types/node on browser environment'"

You know something is wonky when a rimraf is needed as a workaround...

It seems like the powers that be on the typescript side think that this is a matter for package maintainers to deal with, but the reality is messier -- there are different packages that are alternatives for other ones (like react vs. preact for example) where people are trying to use these in the same project, and the solution for dealing with types is not always straightforward:
preactjs/preact#1036

None of the solutions proposed, such as defining types, or remapping using baseUrl/paths actually work. The rimraf is literally the only thing I've found that does work. Do we really want rm rf commands sitting around in our configuration files, waiting for a misplaced asterisk or slash to come along?

Please please please implement this.

lostpebble · 2019-03-14T11:54:33Z

By far this is one of the biggest annoyances in Typescript. Expecting that every single dependency's types are absolutely perfectly built before being able to build your code correctly - we all know this is impossible, developers are not perfect, configuration for TypeScript libraries can be difficult, and I'm struggling with this very thing with Google engineers who have completely messed up their types for libraries I'm using.

The fact that I can't easily just tell Typescript to ignore those types for now and spit out my code is so infuriating. At the core of, its still JavaScript - and these libraries have been built already - I can make use of them now, but TypeScript is being a real productivity blocker here.

These are definition bugs that need to be fixed i would say.

Is the current expectation to really go and fix every single library you depend on's types? What do you do while you wait for your pull requests to be accepted? There are certain situations where "make a pull request" is a viable answer - this is definitely not one of them - because its actually completely unrelated to the issue at hand.

sam-s4s · 2019-03-20T04:52:03Z

Yeah, I'm now facing this problem too. I'd love an exclude for types.

Unfortunately a recent change to angular-cli has added a type dependency in for "node", which breaks all my references to settimeout and setinterval (as their type is supposed to be number, and now is NodeJS.Timeout) :(

leethree · 2019-04-08T12:43:03Z

I'm seeing the same problem in my project and defining types in tsconfig doesn't seem to help. I have to file issues to library that includes @types/node to remove them. e.g. TooTallNate/node-data-uri-to-buffer#8

Would definitely be helpful if there's way to just exclude @types/node.

pvinis · 2019-04-10T08:42:37Z

Having typeRoots keep the order for overloads would be also helpful. This way we can overload the buggy ones at least.

StephenHaney · 2019-04-17T23:13:21Z

Since this is tagged "awaiting more feedback":

We're in the same boat. Web libs with dependencies on server typings are polluting our types with incorrect node types.

The end result is @types/node is ending up in a ton of browser targeting projects.

RyanCavanaugh · 2019-04-18T00:10:19Z

Are people asking for excludeTypeRoots or excludeTypes ? It sounds like a lot more the latter than the former?

sam-s4s · 2019-04-18T00:13:26Z

I can only speak for myself, but I am after an excludeTypes :)
(I agree, it looks like most people seem to want that)

ie. many of us need to exclude @types/node

Update (most) vulnerable dependencies/packages found by `npm audit fix --force --dry-run`. Notes redarding package changes: * The outdated grunt-postcss plugin is replaced by a (maintained) fork for compatibility with newer grunt versions. * karma is updated to v6 and pulls in @types/node which conflicts with TypeScript type definitions by @types/requirejs. Therefore 3rd party type declarations from packages (@types/*) are now explicitly enabled in tsconfig.json – note that there is no other way to exclude from typeRoots: microsoft/TypeScript#18588 * grunt-lintspaces and grunt-contrib-imagemin are replaced as these packages have been not been updated to not depend on vulnerabe dependencies, while grunt-lintspaces and grunt-contrib-imagemin would cause downgrades to older version when running `npm audit fix --force` (because only the older versions do not depend on vulnerable software). * (grunt-contrib-)imagemin is replaced by squoosh (by google) as a) imagemin dependencies ("bin-build" > "download") rely on vulnerable versions of "got". Neither of these packages is currently updated,see kevva/download#224 b) imagemin is unmaintained: imagemin/imagemin#385 and suggests squoosh as replacement * stylefmt is replaced by a maintained fork. There is one remaining packages that pulls in a vulnerability alerts: * jquery-ui is marked as vulnerable (severity: high), but worked on in a separate patch #96497. (We don't actually use the vulnerable library parts though). Vulnerability report before this patch: 74 vulnerabilities (1 low, 30 moderate, 38 high, 5 critical) Vulnerability report after this patch: 1 high severity vulnerability (this is jquery-ui) Commands executed: # Supposed to be non breaking, but broke grunt-css npm audit fix npm remove grunt-postcss npm install @lodder/grunt-postcss # Preparation for `npm audit fix --force` (breaking changes) npm install grunt@^1.5 npm install grunt-lintspaces@^0.10.0 npm remove grunt-lintspaces npm install --save-dev lintspaces-cli npm remove grunt-contrib-imagemin npm install --save-dev npm remove stylefmt npm install --save-dev @ronilaukkarinen/stylefmt npm audit fix --force Releases: main Resolves: #98198 Change-Id: I09df87fe131a499790e6c5f95f1c51e9216b71c2 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/75539 Tested-by: core-ci <[email protected]> Tested-by: Georg Ringer <[email protected]> Tested-by: Stefan Bürk <[email protected]> Tested-by: Benjamin Franzke <[email protected]> Reviewed-by: Georg Ringer <[email protected]> Reviewed-by: Stefan Bürk <[email protected]> Reviewed-by: Benjamin Franzke <[email protected]>

* ci, readme, commands, etc to yarn * root package.json, adding yarn lock * updating circle ci * hack for node types workspace issue: microsoft/TypeScript#18588

k8w changed the title ~~Suggestion: add config excludeTypes~~ Suggestion: add excludeTypeRoots to tsconfig Sep 21, 2017

mhegazy added Awaiting More Feedback This means we'd like to hear from more people who would be helped by this feature Suggestion An idea for TypeScript labels Sep 21, 2017

k8w mentioned this issue Oct 18, 2017

@types/node should be moved to devDependencies. protobufjs/protobuf.js#711

Closed

k8w mentioned this issue Nov 13, 2017

@types/react-dom should not have dependency @types/node DefinitelyTyped/DefinitelyTyped#21310

Closed

4 tasks

bard mentioned this issue Mar 6, 2019

Node and requirejs typings messing up my build rollup/rollup#2142

Closed

davidsoergel mentioned this issue Mar 19, 2019

Can't use tfjs-vis in a React app due to Preact typings collision tensorflow/tfjs#1415

Closed

onetrickwolf added a commit to ProvableHQ/sdk that referenced this issue Oct 10, 2023

hack for node types workspace issue: microsoft/TypeScript#18588

c217012

onetrickwolf pushed a commit to ProvableHQ/sdk that referenced this issue Oct 10, 2023

[Feature] yarn conversion (#766)

0316240

* ci, readme, commands, etc to yarn * root package.json, adding yarn lock * updating circle ci * hack for node types workspace issue: microsoft/TypeScript#18588

This was referenced Oct 11, 2023

Transitive loading of @types/node breaks Request/Response (etc.) types cloudflare/workerd#1298

Closed

[node] Add fetch types DefinitelyTyped/DefinitelyTyped#66824

Merged

justinbhopper mentioned this issue Mar 15, 2024

Upgrade to date-fns v3 palantir/blueprint#6744

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Suggestion: add excludeTypeRoots to tsconfig #18588

Suggestion: add excludeTypeRoots to tsconfig #18588

k8w commented Sep 20, 2017 •

edited

Loading

mhegazy commented Sep 21, 2017

k8w commented Sep 22, 2017 •

edited

Loading

mhegazy commented Sep 22, 2017

k8w commented Sep 25, 2017 •

edited

Loading

mhegazy commented Sep 25, 2017

k8w commented Nov 9, 2017

mhegazy commented Nov 9, 2017

k8w commented Jan 4, 2018 •

edited

Loading

k8w commented Mar 8, 2018

fqborges commented Oct 22, 2018

Venryx commented Oct 23, 2018 •

edited

Loading

fqborges commented Oct 23, 2018 •

edited

Loading

garrettmaring commented Nov 3, 2018

OliverJAsh commented Nov 5, 2018

wallzero commented Jan 27, 2019

AndrewJDR commented Feb 19, 2019

lostpebble commented Mar 14, 2019

sam-s4s commented Mar 20, 2019

leethree commented Apr 8, 2019

pvinis commented Apr 10, 2019

StephenHaney commented Apr 17, 2019 •

edited

Loading

RyanCavanaugh commented Apr 18, 2019

sam-s4s commented Apr 18, 2019

Suggestion: add excludeTypeRoots to tsconfig #18588

Suggestion: add excludeTypeRoots to tsconfig #18588

Comments

k8w commented Sep 20, 2017 • edited Loading

mhegazy commented Sep 21, 2017

k8w commented Sep 22, 2017 • edited Loading

mhegazy commented Sep 22, 2017

k8w commented Sep 25, 2017 • edited Loading

mhegazy commented Sep 25, 2017

k8w commented Nov 9, 2017

mhegazy commented Nov 9, 2017

k8w commented Jan 4, 2018 • edited Loading

k8w commented Mar 8, 2018

fqborges commented Oct 22, 2018

Venryx commented Oct 23, 2018 • edited Loading

fqborges commented Oct 23, 2018 • edited Loading

garrettmaring commented Nov 3, 2018

OliverJAsh commented Nov 5, 2018

wallzero commented Jan 27, 2019

AndrewJDR commented Feb 19, 2019

lostpebble commented Mar 14, 2019

sam-s4s commented Mar 20, 2019

leethree commented Apr 8, 2019

pvinis commented Apr 10, 2019

StephenHaney commented Apr 17, 2019 • edited Loading

RyanCavanaugh commented Apr 18, 2019

sam-s4s commented Apr 18, 2019

k8w commented Sep 20, 2017 •

edited

Loading

k8w commented Sep 22, 2017 •

edited

Loading

k8w commented Sep 25, 2017 •

edited

Loading

k8w commented Jan 4, 2018 •

edited

Loading

Venryx commented Oct 23, 2018 •

edited

Loading

fqborges commented Oct 23, 2018 •

edited

Loading

StephenHaney commented Apr 17, 2019 •

edited

Loading