[Feature] Built-in constraints

[vhiairrassary]

• I'd be willing to implement this feature
• This feature can already be implemented through a plugin

Describe the user story

As a user I don't want to spend too much time learning constraints for basic needs, like enforcing same package version in all my workspaces.

Describe the solution you'd like

Ideally, I would like to use built-in reusable constraints. Currently there are few examples available in the documentation and in this repository.

Instead of copy-pasting:

% This rule will enforce that a workspace MUST depend on the same version of a dependency as the one used by the other workspaces
gen_enforced_dependency(WorkspaceCwd, DependencyIdent, DependencyRange2, DependencyType) :-
  % Iterates over all dependencies from all workspaces
    workspace_has_dependency(WorkspaceCwd, DependencyIdent, DependencyRange, DependencyType),
  % Iterates over similarly-named dependencies from all workspaces (again)
    workspace_has_dependency(OtherWorkspaceCwd, DependencyIdent, DependencyRange2, DependencyType2),
  % Ignore peer dependencies
    DependencyType \= 'peerDependencies',
    DependencyType2 \= 'peerDependencies'.

I would like something like:

enforce_same_version_everywhere()

These built-in constraints would be tested and maintained by experienced prolog developers.

Describe the drawbacks of your solution

• Such built-in constraints may not be suitable for all the use cases.
• More work for the yarn maintainers;

[arcanis]

That would be interesting. In fact, I think even better would be to document how to import rules from the dependencies - Tau-Prolog has a predicate named use_module, maybe we could leverage it? This way, we would just have to suggest users to do something like this:

yarn add @yarnpkg/contrib-constraints

use_module(package('@yarnpkg/contrib-constraints')).

enforce_same_version_everywhere().

That doesn't even sound too complex to implement - mostly adding a branch to Tau-Prolog to support for the case where the arg is a package name rather than a library, and call require in such a case (the main problem is that the require will have to be made on behalf of the application project, not Tau-Prolog itself, since it doesn't list @yarnpkg/contrib-constraints in its own dependencies):

https://github.com/jariazavalverde/tau-prolog/blob/24218a785d65d84dc7ee4141446f020a5735fd9f/modules/core.js#L3175

Would you be interested to lead this?

[vhiairrassary]

I just had a look at Tau-Prolog's use_module predicate and adding a branch is not enough as use_module only enables the library, it has to be loaded first using regular JS code. Example:

• Loading: https://github.com/jariazavalverde/tau-prolog/blob/5b64f21727e01bf89da5739e96a5e3c8daa6b7bd/examples/nodejs/fruit.js#L9
• Enabling: https://github.com/jariazavalverde/tau-prolog/blob/5b64f21727e01bf89da5739e96a5e3c8daa6b7bd/examples/nodejs/fruit.js#L17

Let's ask the maintainers first about their feelings regarding use_module(package('myPackage')).

Quick question: what's the purpose of constraints_min_version(1). in the constraints.pro file of this repository?

[arcanis]

Quick question: what's the purpose of constraints_min_version(1). in the constraints.pro file of this repository?

Hmm the initial idea was to have a way to specify against which version of the constraint engine should the rules be executed (or at least print a warning if they wouldn't match, kinda like cmake_minimum_version). Thinking more about it, however, I'm not sure it's super useful since we recommended to version the Yarn release in the repository anyway 🤔

[vhiairrassary]

What about loading the additional predicates when the constraints module is loaded (https://github.com/yarnpkg/berry/blob/master/packages/plugin-constraints/sources/tauModule.ts#L119)? But it means users would have to reference them outside of the constraints.pro file, which may not be a good idea 🤔

Also, do you think @yarnpkg/contrib-constraints should export:

• a string directly included in the constraints.pro file (i.e. prolog code)
• a pl.type.Module

Some constraints may be easier to write as prolog code (like the one originally referenced in this issue).

[arcanis]

Sorry, forgot to answer!

What about loading the additional predicates when the constraints module is loaded

I'd prefer to reference the relevant plugins from the .pro files, but if we can't do this then a reasonable approach would be to declare an array of string setting (constraintsPreload?) that would be required, instantiated, and injected.

Also, do you think @yarnpkg/contrib-constraints should export

We probably can support both? If it exports a string we convert it into a module, and if it exports a function we call it with tau-prolog as parameter and use the result as a module (or list of modules, rather) 🤔