What do you not like about DefinitelyTyped as a user and contributor?

[orta]

What do you not like about DefinitelyTyped as a user and contributor?

Hey folks, we, the TypeScript team at Microsoft, are interested in understanding pain points for people using and contributing to DefinitelyTyped.

About this time last year, we drastically changed the workflow for contributors to DefinitelyTyped (one of the most active repos on GitHub) to allow for self-serving Pull Requests. Since then, we've been refining that process and improving the automation to cover more cases and consolidated all of the DefinitelyTyped tooling into one monorepo and re-vamped the search. Now that these systems have matured, we're thinking about what the right things to look at next, and would love input from the folks who are writing definitions daily.

I've explicitly given an opening for users of @types to provide feedback here too, given that it's quite likely any requests as a user of DT will affect contributors too.

We've used a format for this before which worked well in #31983 which is for people to reply to this issue with a single idea per comment.

We've got a meeting booked on the 20th to go through feedback and see what's we can do 👍🏻

Please do: reply with 1 comment per issue. Add tags if you'd like to help with search for others and ease-of classification. If you have a link to an existing issue, that would be super useful too.

If you see that someone has already pitched your idea, please use the emoji reactions to +1 it, we will be deleting duplicates and off-topic replies. If you want to add more to a topic, see if it has an attached issue and leave more feedback there. If there isn't, come chat in the DefinitelyTyped chatroom in the TypeScript Community Discord.

Please do not use this thread for discussions about the TypeScript language itself, and as with all issues please conform to the code of conduct. We all want to see improvements.

Template - feel free to copy & paste

### [title]

[message]

Tags: `[tags]`

For example

One of mine:

---

There is no REPL for Type Definitions

I would like to use the Playground to work with .d.ts files to be able to share problems with others

Tags: playground

---

[orta]

There is no REPL for Type Definition writing

Making a good .d.ts file is kinda of a unique skill, the many ways in which your types are consumed can mean it's hard to know ahead of time what the right setup for a .d.ts file looks like.

It'd be good to have an environment where I could easily work with a set of projects that have different import options in order to test that the exports from my lib indeed work like expected.

Tags: playground

[dylang]

Link homepage in package.json to the exact page where the type source is located on Github.

Example type:
https://www.npmjs.com/package/@types/webpack-dev-middleware

Currently we see:

Homepage: https://github.com/DefinitelyTyped/DefinitelyTyped#readme
Repository: https://github.com/DefinitelyTyped/DefinitelyTyped#readme

This makes it hard to see what the types look like before installing them, or where to find them if we want to make changes.

Ideally, homepage in the package.json would link to something like https://github.com/DefinitelyTyped/DefinitelyTyped/tree/master/types/webpack-dev-middleware - and perhaps an automatically generated README.md on that page specific to this project.

Tags: homepage, repository

[43081j]

More docs/guides on generating types for existing projects

Many authors of existing projects are afraid of the burden of having to maintain typescript types on top of what they already have to maintain.

I don't think there is actually much of a burden anymore as you can quite easily generate type definitions from JSDoc of an existing project without migrating it to typescript.

However IMO there's not enough official documentation on this, and not enough emphasis on it when introducing existing authors to typescript. This is what leads to them assuming it must be a huge job they won't have time for or a new skill they need to learn.

There should be a push to make DT smaller by sharing the knowledge of how to generate types in source repos, basically.

[dylang]

npm deprecate type package once the original package has types.

Unless we see an announcement in a changelog or release notes, it's difficult to know when we can remove an @types package from our repository.

Example: webpack@5 now includes types, so @types/webpack can be removed. The deprecation message would be something like Webpack now includes types starting at 5.0.0. You can safely remove @types/webpack.

npm deprecate allows deprecating of a version range, so we'd just deprecate @types/webpack@>=5.0.0

https://docs.npmjs.com/cli/v7/commands/npm-deprecate

Tags: deprecation, deprecate, old @types

[nirtamir2]

Update of @types packages with the corresponding library version

Ideally @types packages should be with the same minor version of the original package (and the latest patch) as described here.

When upgrading dependencies it can be easy to forget to upgrade the correlated @types to the same version too.

Also, because it is maintained separately from the library, the right version could not exist when updating - leading to a mismatched version.

Tags: update, version, dependency

[Pokute]

Issue and PR titles have too wide variety since there's no template for the issue titles.

I'm not sure if GitHub allows issue/PR titles templates it, but having them unified would be nice. For example, react as a search term gives a lot of packages, while [@types/react], with more uniform titles, would drop a lot of noise.

On the other hand, above example might miss something like react-dom and that might be a minus.

Tags: issue, pr, title

[Maxim-Mazurok]

Make automatically generated types for Google APIs first-class citizens on DT

I auto-generate types for Google APIs, and there's no way to properly sync them to DT.

I used to create PRs from one account and approve them from another, using GitHub API (DefinitelyTyped/dt-mergebot#98). That was a beautiful piece of automation but was considered bad (DefinitelyTyped/DefinitelyTyped#49235).

Now I publish generated types to npm (example) and reference them in the corresponding DT package (example). This still has a challenge of syncing new and obsolete APIs (Maxim-Mazurok/google-api-typings-generator#401) which currently is manual and results in huge PRs (DefinitelyTyped/DefinitelyTyped#52618). Also, it's bad for versioning (DT package version stays the same), but this can be managed through lock-file, so I guess it's fine. But could be better :)

I have some ideas on how to solve this if anyone is interested. Please, find my contacts at https://maxim.mazurok.com

Tags: automation, generation, google APIs

[eps1lon]

Queue for PRs

I know you mentioned that the boards are one but it's either bugged or I don't understand how it works.
PRs above my PR are sometimes older, sometimes newer. It would remove a lot of frustration if I could check how many more PRs need review (think about traffic lights displaying a timer next to the lights). Right now I'm just idly waiting for 20+ days PRs to get attention (and I even had 40+ days once I believen) and I don't want to ping people constantly (which I also don't think is fair to put on PR authors as a burden).

[peterblazejewicz]

Solo owner package support to avoid backbenching

There is a lot of folks and/or organization using DT power to publish content (both for the benefit of the community and, obviously, the published project). see @Maxim-Mazurok comment for one of those scenarios.

There is a lot of those, say a single person working on TS types for interesting JS topics and publishing through DT or organization, that adopted JS, but maintain or publish .d.ts files through DT. Because those are large ('huuuge' in old american), usually non one helps those solo projects until eventually DT maintainer arrives. This impacts consumption of changes of those packages (DT package can be for a Google api or for well known UI projects, say open sourced IBM effort, NPM native code already published literally weeks ago).
Sometimes those DT types are for upcoming JS features (schemas and backing types for non-released apis), so literally, the audience that know DT topic is sparse. This delegates PR to backbanches.

We could have solo owners txt on tooling, that would bypass required DT steps, after all checks passed.

Thx!

Tags: pr, owner

[AlCalzone]

Lack of maintainer assistance on critical packages / false negative CI checks from other packages

I usually have a good experience with the types I own. Create a PR, get someone to review, done!

Nearly all my negative experience comes from the interaction around this PR. I tried to improve the promisify typings in node by using conditional types after being asked to do so by @DanielRosenwasser (which lead me to believe there was some interest by the TS team). That package has a particular difficult structure to support different TS versions, which made the following interaction even more painful.

It took 3 weeks to get a maintainer review, which I addressed within a day. In the following 6 months (!) I never got another review despite asking for it, but multiple pings from @typescript-bot because:
a) some dependent package broke their typings (which caused my PR to fail its build)
b) other node PRs got merged that required me to fix complicated conflicts
c) or simply because nothing happened in that PR in a few days

As you may infer from my comments in the PR, I got frustrated and gave up on it (although I still think the change is good). In the end I'd hope for a bit more drive and team support behind the "core" typings.

Tags: review process, critical package

[BendingBender]

CLI tool to consume @types packages

It would be very nice to have a CLI tool that uses the list of packages in package.json to install all the missing but available type definitions. Probably with a couple of flags, like for example only for dependencies or only for devDependencies with possibilities to include/exclude specific packages.

Maybe even better: a replacement tool for npm install [--save|--save-dev] packageName - types-install [--save|--save-dev] packageName that would be able to install a package along with the corresponding definition (if available) in a compatible version. So running types-install --save-dev webpack@4 would install webpack@4 along with @types/webpack@4.

It could install @types packages when available, simply skip installing @types packages if a package has types bundled and propose to create new types for packages that don't already have types on DT along with first instructions on how to do it.

Tags: tooling, cli

[ExE-Boss]

Using GitHub’s discussions feature

I feel like enabling GitHub’s Discussions feature would be beneficial, with this issue being a decent candidate for migration.

Tags: meta

[eteeselink]

Encourage contributors to send typedefs to library repo first

While plenty of library authors want little to do with TypeScript, even more simply don't know how to ship or maintain good TypeScript bindings. For the latter category, it would be much more useful if someone contributes a TS typedef to the core repo instead of to DefinitelyTyped. In a way, DefinitelyTyped is a bit of a cop-out, a plan B. A necessary plan B, but a plan B nevertheless.

For example, I feel like it's weird that the How can I contribute guide appears to actively discourage communicating with the author of the open source package at hand. Or, well, not actively discourage, but it's simply not even presented as an option. Isn't that weird? Wouldn't the home repo be the best place for the typedefs to live?

I think it should be a goal of DefinitelyTyped to one day not be necessary anymore. Sure, it'll never happen, because TS will never have 100% penetration, but it should be the direction. But right now, it's more like DefinitelyTyped is poised to be an ever-expanding mountain of half-maintained typedefs that continuously run the risk of lagging behind their JS packages. It's better than no typedefs, but way worse than what it should be.

Therefore, I think the TS/DT teams could do more to help library authors and/or contributors ship types directly. Eg:

• Write HOWTOs for various common scenarios (generate from JSDoc, hand-write, generate from actual typescript sources, etc etc)
• Add/link these in the contributing guide.
• Have the contributing guide actively encourage communicating with the library author instead of going behind their backs.
• Come up with a simple, noob-proof mechanism that lets library authors pull an existing DT typedef into their main repo (and have the @types/somelib package somehow stay compatible - maybe an export ... from "somelib" oneliner? or just unpublish from npm? I'm not even sure, and I doubt a non-TS-expert library author will find this easier)

Tags: meta