[dts-lint] Support testing multiple times with different compiler options
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 25/100
- Issue type
- Feature
- Clarity
- Needs clarification
- Activity status
- Stale
- Tech stack
- typescript
Research direction
Start by reviewing dts-lint's existing handling of tsconfig.json, compiler options, and test execution. Compare the proposed solution-style referenced configurations with a dedicated dts-lint configuration, then define how multiple environments are selected and reported. Done means one test set runs successfully with and without lib-dom.
Written by the indexing model from the issue text.
Description
I just created this hacky workaround to a problem that I'm not sure a lot of other users have, but I figured it was worth capturing something here.
The basic problem is that @types/node needs to behave differently depending on whether or not the consuming project includes lib-dom. I'd like to write one set of tests that runs with the option lib: ['dom'] and one without. The hacky workaround is to create a tsX.Y "version" folder, which just re-uses code and tests from another version, but has its own tsconfig file. It would be better if dts-lint supported some way of specifying multiple environments.
I don't have a specific implementation in mind. Maybe if it finds a "solution style" tsconfig.json, it would run tests once for each referenced tsconfig? Maybe dts-lint gets its own config file where I can specify an array of compiler options to change across multiple runs?
- Dominant language
- TypeScript
- Stars
- 422
- Forks
- 238
- Avg merge
- 1d 4h
- Merged PRs (30d)
- 8
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: 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 1 day
-
Difficulty 4/5 3-5 days Newbie friendliness 32/100
microsoft/DefinitelyTyped-tools#1230 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 4/5 3-5 days Newbie friendliness 42/100
microsoft/DefinitelyTyped-tools#1229 ·
Maintainers usually reply within 1 day
-
mergebot staleness comments do not respect tooManyOwnersPossibly taken @copilot-swe-agent claimed this 322 days ago. Open
microsoft/DefinitelyTyped-tools#1218 · 1 reaction · 1 assignee ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 45/100
microsoft/DefinitelyTyped-tools#1211 · 1 comment ·
Maintainers usually reply within 1 day
All issues in microsoft/DefinitelyTyped-tools
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
nats-io/nats.docs.v2#101 ·
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 72/100
profullstack/ugig.net#601 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 90/100
github/codeql-action#4202 ·
Maintainers usually reply within 1 day
-
agents: formatReport/reportOrigin only importable through an entry that loads every runtime (~1.5 s)Open
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day