How can library authors test types against multiple TS versions?
Maintainers usually reply within 3 days
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 20/100
- Issue type
- Feature
- Clarity
- Needs clarification
- Activity status
- Stale
- Tech stack
- typescript
Research direction
Start with the dtslint README and the references to DefinitelyTyped-tools and @definitelytyped/dtslint in the issue. Compare the listed approaches for testing library types across TypeScript versions, then define a supported approach for libraries outside DefinitelyTyped. Done should include a documented, maintainable way to run those multi-version type checks.
Written by the indexing model from the issue text.
Description
Hello, Emotion contributor here. 👋 We have been using dtslint to check our (rather complex) TypeScript definitions against multiple versions of TypeScript.
The problem is that the dtslint README indicates that dtslint has moved into DefinitelyTyped-tools, and DefinitelyTyped-tools is not intended for public consumption.
How are library authors supposed to test their types against multiple TypeScript versions? (When the types are in the library's repository rather than DefinitelyTyped.)
Here are some options I have considered, though none of them seem particularly good:
- Library authors use
@definitelytyped/dtslint, even though it is not intended for public consumption. - Someone forks dtslint and starts maintaining it again.
- Someone creates a new tool that enables testing against multiple TypeScript versions.
- Each library that needs to test on multiple TS versions writes a script that "manually" installs different TS versions from npm.
- Library authors give up on testing against multiple TS versions and instead test against a specific version or tag, e.g. the latest supported TS version (3.9 currently),
typescript@latest, ortypescript@next.
- Dominant language
- TypeScript
- Stars
- 423
- Forks
- 237
- Avg merge
- 18h 18m
- Merged PRs (30d)
- 11
Getting set up
We have not checked this project's setup files yet. Start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from microsoft/DefinitelyTyped-tools
-
Difficulty 3/5 1-2 days Newbie friendliness 66/100
microsoft/DefinitelyTyped-tools#1324 · 8 comments ·
Maintainers usually reply within 3 days
-
Difficulty 4/5 3-5 days Newbie friendliness 32/100
microsoft/DefinitelyTyped-tools#1230 · 1 comment ·
Maintainers usually reply within 3 days
-
Difficulty 4/5 3-5 days Newbie friendliness 42/100
microsoft/DefinitelyTyped-tools#1229 ·
Maintainers usually reply within 3 days
-
microsoft/DefinitelyTyped-tools#1218 · 1 reaction · 1 assignee ·
Maintainers usually reply within 3 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 45/100
microsoft/DefinitelyTyped-tools#1211 · 1 comment ·
Maintainers usually reply within 3 days
All issues in microsoft/DefinitelyTyped-tools
Similar issues
-
bug
Difficulty 1/5 Under an hour Newbie friendliness 88/100
StabilityNexus/Fate-EVM-Frontend#153 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
code-yeongyu/oh-my-openagent#9039 ·
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
Tencent/teamai-cli#862 ·
Maintainers usually reply within 1 day
-
bug good first issue hacktoberfest redis
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
libredb/libredb-studio#1164 ·
Maintainers usually reply within 1 day
-
flake
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
Maintainers usually reply within 1 day