Skip to content

Comments

refactor: add CLI config schema to make sure we don't miss options#5126

Merged
sheremet-va merged 16 commits intovitest-dev:mainfrom
sheremet-va:fix/cli-options
Feb 8, 2024
Merged

refactor: add CLI config schema to make sure we don't miss options#5126
sheremet-va merged 16 commits intovitest-dev:mainfrom
sheremet-va:fix/cli-options

Conversation

@sheremet-va
Copy link
Member

@sheremet-va sheremet-va commented Feb 6, 2024

Description

This PR makes it easier for us to make sure we didn't forget to add a CLI option because it requires an explicit opt-out.

This is also a continuation of #3983 to make sure all types are correct.

Closes #3983
Fixes #3962

Please don't delete this checklist! Before submitting the PR, please make sure you do the following:

  • It's really useful if your PR references an issue where it is discussed ahead of time. If the feature is substantial or introduces breaking changes without a discussion, PR might be closed.
  • Ideally, include a test that fails without this PR but passes with it.
  • Please, don't make changes to pnpm-lock.yaml unless you introduce a new test example.

Tests

  • Run the tests with pnpm test:ci.

Documentation

  • If you introduce new functionality, document it. You can run documentation with pnpm run docs command.

Changesets

  • Changes in changelog are generated from PR name. Please, make sure that it explains your changes in an understandable manner. Please, prefix changeset messages with feat:, fix:, perf:, docs:, or chore:.

@netlify
Copy link

netlify bot commented Feb 6, 2024

Deploy Preview for fastidious-cascaron-4ded94 canceled.

Name Link
🔨 Latest commit 37cd585
🔍 Latest deploy log https://app.netlify.com/sites/fastidious-cascaron-4ded94/deploys/65c4f1ac5c31cd00089c6fa4

@sheremet-va sheremet-va changed the title refactor: add CLI config to make sure we don't miss options refactor: add CLI config schema to make sure we don't miss options Feb 6, 2024
@sheremet-va sheremet-va marked this pull request as ready for review February 6, 2024 18:45
Copy link
Member

@AriPerkkio AriPerkkio left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall looks really nice. 🙌
I think this is a solution that we can maintain quite easily. I'm glad to see the --someOption --someOption.nestedOption=value working without specifying the .enabled explicitly.

Some quick comments below for now. I'll do proper review later this week and do some manual testing.

Copy link
Member

@AriPerkkio AriPerkkio left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

to make sure we didn't forget to add a CLI option because it requires an explicit opt-out.

This seems to work for top-level configurations, but not for sub-commands.

I have not yet finished reviewing this completely, but I'm confident enough about the changes. Feel free to merge this if needed. I'll look into this more later this week once I find some time.

@sheremet-va
Copy link
Member Author

This seems to work for top-level configurations, but not for sub-commands.

Can you give an example when this doesn't work? If I remove any nested commands, I get a type error.

@AriPerkkio
Copy link
Member

Can you give an example when this doesn't work? If I remove any nested commands, I get a type error.

I tested this by adding new option to provider specific coverage options. But when I add an option to all providers, then it raises an error on CLI definitions. So it's got something to do with conditional types. Detecting all those combinations might be difficult so the current implementation is enough I think.

@sheremet-va
Copy link
Member Author

sheremet-va commented Feb 8, 2024

I tested this by adding new option to provider specific coverage options.

Ah, yes. This only happens with provider because it has a complex type, and TypeScript uses the smallest common denominator when checking this. I think requiring all options to be available in CLI would be a mistake here actually.

Copy link
Member

@AriPerkkio AriPerkkio left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me, thanks! Also thanks to @LorenzoBloedow for earlier work on #3983! 🙌

@sheremet-va sheremet-va merged commit a931646 into vitest-dev:main Feb 8, 2024
@sheremet-va sheremet-va deleted the fix/cli-options branch February 8, 2024 15:48
@LorenzoBloedow
Copy link
Contributor

Also thanks to @LorenzoBloedow for earlier work on #3983! 🙌

No problem, glad you guys found a solution! If you need any help feel free to hit me up on Twitter!

@sheremet-va sheremet-va added this to the 1.3.0 milestone Feb 9, 2024
@AriPerkkio
Copy link
Member

AriPerkkio commented Feb 10, 2024

This broke browser-simple project of ecosystem-ci: https://github.com/vitest-dev/vitest-ecosystem-ci/actions/runs/7854132436/job/21434556372

It doesn't find test cases to run. When this commit is reverted all works fine.

cli
.command('[...filters]')
.action((filters, options) => start('test', filters, options))

$ pnpm test

> @vitest-tests/browser-simple@ test /z/y/x/browser-simple
> vitest --browser=firefox

{
  filters: [ 'firefox' ],
  options: { '--': [], color: true, browser: { enabled: true } }
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

command line flags don't override config file

4 participants