Improves JS constraints

[arcanis]

What's the problem this PR addresses?

• It's difficult to use JS constraints because they're not covered by types.

• The automatic constraints check occurs before install; this has a couple of critical issues:

  • If a constraint fails because of yarn add, Yarn will request to call yarn constraints for details but won't persist the changes on disk. As a result, yarn constraints will remain silent.
  • If a constraint has to be fixed by calling multiple commands (for example to add a dependency in multiple places), users currently have to manually edit the package.json (because the yarn add / yarn up changes aren't persisted on disk).
  • If the yarn.config.js file call require('./.pnp.cjs') (a bit experimental at the moment, but why not), it causes problems during merge conflict resolution (the merge conflicts in the .pnp.cjs file aren't resolved until after the install finishes).

How did you fix it?

• Created a types package @yarnpkg/types - it's meant to only contain "dumb" types, and only contains the constraints context at the moment. Later on, I plan to expand it to also cover plugins, but that'll be a separate project.

• The automated constraints checks will now occur after install rather than before.

Checklist

• I have read the Contributing Guide.

• I have set the packages that need to be released for my changes to be effective.

• I will check that all automated PR checks pass before the PR gets reviewed.

[RDIL]

🎉

[koshic]

@arcanis thx for this PR! Could you please share your plans about this feature?

As an example, for my projects it still doesn't work due to 'type: module' in root package.json and ERR_REQUIRE_ESM fail. Minimal requirement is to support .cjs (instead of hardcoded 'ppath.join(this.cwd, yarn.config.js)'), but existing 'constraintsPath' option should be enough too.

[arcanis]

I think it'd be reasonable to change the logic to yarn.config.cjs, since it's already the extension we use for .pnp.cjs 🤔