Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Should we set '"types": []' for 'tsc init'? #39354

Open
DanielRosenwasser opened this issue Jul 1, 2020 · 6 comments
Open

Should we set '"types": []' for 'tsc init'? #39354

DanielRosenwasser opened this issue Jul 1, 2020 · 6 comments
Labels
Committed The team has roadmapped this issue In Discussion Not yet reached consensus Suggestion An idea for TypeScript

Comments

@DanielRosenwasser
Copy link
Member

DanielRosenwasser commented Jul 1, 2020

Very few people understand the automatic @types inclusion behavior, it often causes packages to conflict, and it is often a program construction performance foot-gun.

Maybe we should output a field like this in compilerOptions.

// Add packages with global definitions that can't be imported here.
// Remove entirely to auto-include all '@types' packages.
"types": []

What do others here think?

@DanielRosenwasser DanielRosenwasser changed the title Should we set '"types": '[]' for 'tsc init'? Should we set '"types": []' for 'tsc init'? Jul 1, 2020
@orta
Copy link
Contributor

orta commented Jul 1, 2020

Yes

@RyanCavanaugh
Copy link
Member

Hmm, also yes

@danielrentz
Copy link

+1 from me. It was my first step in several TS projects to define "types" fields in every tsconfig.json with explicit type imports to prevent pollution of the code with unneded types from node_modules (e.g., I want @types/node in the grunt scripts, but not in the web scripts, and so on).

@Bnaya
Copy link

Bnaya commented Aug 27, 2020

I'm also +1, as setting specific "types" :[] entry (and lib) is the first thing after tsc --init for me
But it might hinder the autocomplete/auto import features of yet-to-be imported packages, so it must be very documented

@sandersn
Copy link
Member

sandersn commented Sep 18, 2020

From discussion in the design meeting: we would like to do this, but only after we've come up with a basic @types/node workflow that's as easy as the current one:

  1. import * as fs from "fs"
  2. error "you need to install @types/node."
  3. $ npm i @types/node
  4. Done.

Same for jest, when using describe or expect.

@Bnaya
Copy link

Bnaya commented Sep 18, 2020

Maybe add new error + autofix for this kind of things?

@DanielRosenwasser DanielRosenwasser added the Committed The team has roadmapped this issue label Dec 7, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Committed The team has roadmapped this issue In Discussion Not yet reached consensus Suggestion An idea for TypeScript
Projects
None yet
Development

No branches or pull requests

6 participants