I marked the PR as Draft as I haven't finished with the implementation, e.g. I still need to add unit tests but I wanted to ask the project maintainers' opinion (especially @tido64) considering this is my first feature addition to this repo. I appreciate any help and suggestion!

thanks for sending it over!
Super small thing, can you run yarn change locally to generate the changesets ? that will make CI go green

thanks for sending it over! Super small thing, can you run yarn change locally to generate the changesets ? that will make CI go green

Sure, that's definitely on my list. You know what, I'll update the PR description with checkboxes for the remaining tasks and if I forgot something you can call that out!

Getting back to changeset, what kind of version bump you think this change warrants?

Getting back to changeset, what kind of version bump you think this change warrants?

@tido64 any preferences? If we want to be close to the semver definition I'd say we should go with minor:

MINOR version when you add functionality in a backward compatible manner

since it's a new feature

@balazsgerlei: Are you unblocked to continue working on this? If you don't have the time, let me know. I wouldn't mind taking over and pushing it over the finish line. 😄

@balazsgerlei: Are you unblocked to continue working on this? If you don't have the time, let me know. I wouldn't mind taking over and pushing it over the finish line. 😄

I've been indeed very occupied with personal stuff so I had little to no free time after work to attend to this. It would be still a nice challenge to finish this so I'll try to allocate some time for it and if I couldn't do it this week I'll let you know, but thanks for offering to take over!

I've been indeed very occupied with personal stuff so I had little to no free time after work to attend to this. It would be still a nice challenge to finish this so I'll try to allocate some time for it and if I couldn't do it this week I'll let you know, but thanks for offering to take over!

Take the time you need to finish this. No pressure. Just making sure you're not waiting to hear from us 😉

Okay, it took a while, I've finally had some time to update this.

I implemented the two distinct diff mode options, what I'm not sure about is how and where to handle if the option is not set correctly. It should not happen since the only two valid options are delcared in cli.ts though I feel like it should still be handled in e.g. check.ts. I could add a simple isDiffMode function similarly to isKitType in initialize.ts before diff is called in checkPackageManifest but I don't see any ErrorCode (which is what checkPackageManifest returns) that would be a good fit and I was hesitant to add a new ErrorCode for this, though that might be the best choice.

Can I ask for some guidence on this @tido64 @kelset ? Thank you!

Hey @balazsgerlei Tommy is currently on a break; I'll throw in my 2C$ in the meantime.

Because we are setting the options via .choices from yargs directly I don't think we necessarily need to handle the error case you are mentioning directly because it should be handled by yargs itself.

What happens currently if you try to run the command and passing an invalid option?

Hey @balazsgerlei Tommy is currently on a break; I'll throw in my 2C$ in the meantime.

Because we are setting the options via .choices from yargs directly I don't think we necessarily need to handle the error case you are mentioning directly because it should be handled by yargs itself.

What happens currently if you try to run the command and passing an invalid option?

The available options are listed and at the end it also tells you what you did wrong:

Invalid values:
Argument: diff-mode, Given: "xyz", Choices: "strict", "allow-exact-version"

That's what I also meant is that when using the script in Terminal you basically cannot pass the wrong argument to the actual logic, just that it would be more precise to handle that case somewhere e.g. in check.ts. That said, I'm more than happy to move forward like this, I would really like if I/we can get to the finish line. 😄

So I think I will continue with the unit tests like this and in the time being, let me know if you have another solution in mind or if @tido64 comes back and has a different opinion!

Thank you for the PR, we also need that feature in our team. I was about to implement that myself until i saw this PR 😄.

I have one small suggestion that would make this ideal for us, currently the diff-mode allow-exact-version only checks for the exact version, as the name suggests. It would be great if there would be another option, e.g. allow-in-range, which would allow all versions which satisfy the version range of the capability.

The following would be valid then:
capability: ^0.73.0
valid: ^0.73.1 ^0.73.9 0.73.2
invalid: ^0.74.0 0.74.0