feat: add --check flag, deprecate --no-check flag

[kitsonk]

Ref #11340

[lucacasonato]

I am not in favor of landing this as is in a patch release. It silently changes the behaviour of many CI pipelines.

[lucacasonato]

I think all unit and integration tests should have check enabled.

[caspervonb]

As the plan is now per the referenced issue, this will silently disable type checking in our std smoke tests and cli unit tests when we make it default.

So we patch that here sure but the same applies to every other CI workflow out there so we'll end up having CI matrices that go up to 1.12 and then after 1.12 it is a different CLI interface?

This will also completely break deno test --no-run and turn it into a no-op.

[kitsonk]

To be clear this only adds --check and deprecates --no-check, as stated in the issue, there will be two PRs. The second will change the default behaviour without flags.

Also, it is planned for a minor release, not a patch release.

[kitsonk]

As the plan is now, this will disable type checking in our std smoke tests and cli unit tests when we make it default.

Not if the yet to be raised PR adds --check.

Also this will completely break deno test --no-run and turn it into a no-op.

Not necessarily. You are assuming something that doesn't exist yet. It is a valid concern that can be addressed in the PR the doesn't exist yet.

Again, as I stated in the issue, the plan was to this PR and then figure out how disruptive the changes would be for the follow up PR before committing to when it would occur.

[nayeemrmn]

I think this change should be coupled with the other. It adds a flag that does nothing and deprecates a flag that isn't replaceable yet. Seems like an unreliable way of gauging disruption, if that's the purpose.

[ry]

We have decided not to land this for the 1.12 release. There's clearly some controversy here, so we'll lay out the plan more carefully in an issue, discussing the reasoning behind the no-check-by-default change and a plan for how we can responsibly introduce this change.

Tentatively adding this PR to the 1.13 milestone.

Let's move further discussion back to #11340.

[kitsonk]

Closing in favour of #11810