fix(jest-validate): Allow deprecation warnings for unknown options

[dj-stormtrooper]

Summary

As discussed here: #14490 (comment)

Current deprecation logic is not flexible because unrecognizedOptions check runs before the deprecation check and we need to keep all deprecated options in allowedOptions config. This PR allows printing deprecation notice for any options, which makes process of deprecation more simple

Test plan

I checked the behavior with jest-cli, passing the option which is not supported anymore (and therefore we don't have it in allowedOptions)

---

Then I added collectCoverageOnlyFrom to the allowed args and checked the other scenario: deprecated option is allowed in config (soft deprecation)

---

Both scenarios are covered by unit test

[netlify]

✅ Deploy Preview for jestjs ready!

Built without sensitive environment variables

Name	Link
🔨 Latest commit	573aae3
🔍 Latest deploy log	https://app.netlify.com/sites/jestjs/deploys/64ff511155739b0008a96fa4
😎 Deploy Preview	https://deploy-preview-14499--jestjs.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[SimenB]

If we log a deprecation warning, can we avoid also printing an "unrecognised" error? We'd still want to fail I guess, so maybe we need to allow some deprecations to also fail instead of just warning?

[dj-stormtrooper]

If we log a deprecation warning, can we avoid also printing an "unrecognised" error? We'd still want to fail I guess, so maybe we need to allow some deprecations to also fail instead of just warning?

Sounds good, I can see 2 options how to implement this:

1. Add field error: bolean or warning: boolean to Deprecated.ts . This will be a breaking change for jest-config because current API of these entries is (options) => string
2. Always throw an error on deprecation check if argument is not presented in the allowedOptions list

Second one makes more sense to me

[dj-stormtrooper]

@SimenB I updated the PR with fatal behavior (without any breaking changes), see the example:

---

If collectCoverageOnlyFrom option is removed from the allowed args list:

---

If collectCoverageOnlyFrom is still in the allowed args list (soft deprecation that allow the usage)

---

Both scenarios are covered by unit tests

[SimenB]

wonderful, thanks!

Could you update its docs as well? https://github.com/jestjs/jest/blob/main/packages/jest-validate/README.md

[SimenB]

should be features I think

[dj-stormtrooper]

Could you update its docs as well

Good idea, thanks, added the example of usage

[SimenB]

Thanks! Just a quick prettier fix in the readme and this should be good to go 👍

[SimenB]

https://github.com/jestjs/jest/releases/tag/v29.7.0

[github-actions]

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Please note this issue tracker is not a help forum. We recommend using StackOverflow or our discord channel for questions.