Proposal for dep-check 2.0 (new config scheme + rename)

[kelset]

Description

RFC to discuss further the new new configuration scheme for dep-check originally proposed here #1638

You can read the formatted text here, please leave comments inline to discuss.

[kelset]

(sidenote: we'll also want to do the renaming bit as part of this effort: #484)

[kelset]

gentle nudge @afoxman @dzearing @JasonVMo - would be great to get your feedback in so that we can start making a plan of action once we have agreement on the way forward.

[AlekhyaYalla]

I have a few questions on dep-check 2.0 features & timelines. I would like to get your confirmations on the below. Thanks!

1. What would the timelines be for the dep-check 2.0 release?
2. To support peerDependencies by defining with the "production" key and defining more than one profile/presets for a dependency,
   Can we have the functionality of giving a range to a package with a "peer" key, so that if that dependency is there in peerDependencies section, that range would be used for alignment in the peerDependencies section
   Eg: Today we need a similar configuration like this

{
  "dep-check": {
    "requirements": {
      "development": [
        "react@18"
      ],
      "production": [
        "react@>=16.13.0  < 18.0.0"
      ]
    }
  }
}

Proposal: Can we have similar to the below in profile itself

{
"react":{
      "name":"react",
      "version":"17.0.1",
      "peerRange": ">=16.8.1 <18.0.0
}

3. Currently with dep-check 1.0, if a profile is given in the dep-check command, that would be used for alignment for the dependencies defined in the profile. But if dependencies like react/react-dom/react-native are missing in the profile, the global(Github) 0.64 profile is getting used for alignment. I think this would be changed in dep-check 2.0, as we provide which presets has to be used for alignment, isn't it?

4. In dep-check 1.0 we cant mention more than one profile, but with dep-check 2.0 we can align with more than one profile with "requirements" as an array, isn't it?

5. With dep-check 2.0, we should be able to call/define a profile with any string eg: "default-profile", right? Cause in RFC proposal I see every requirement is based out of a dependency with a version eg: react@^18.0 / core@0.66. Can I define a profile irrespective of a dependency, declare the dependencies of my interest to be aligned in a single profile and use it for alignment on all of the packages?

[tido64]

1. What would the timelines be for the dep-check 2.0 release?

Depending on scheduling and any unforeseen circumstances, I don't expect the implementation to take more than a few weeks.

2. To support peerDependencies by defining with the "production" key and defining more than one profile/presets for a dependency,
   Can we have the functionality of giving a range to a package with a "peer" key, so that if that dependency is there in peerDependencies section, that range would be used for alignment in the peerDependencies section
   Eg: Today we need a similar configuration like this

{
  "dep-check": {
    "requirements": {
      "development": [
        "react@18"
      ],
      "production": [
        "react@>=16.13.0  < 18.0.0"
      ]
    }
  }
}

Proposal: Can we have similar to the below in profile itself

{
"react":{
      "name":"react",
      "version":"17.0.1",
      "peerRange": ">=16.8.1 <18.0.0
}

This seems at odds with the consistency checks that dep-check provides. You should be able to get the same effect by applying the following preset:

{
  "react-library-production": {
    "name": "react",
    "version": ">=16.8.1 <18.0.0"
  }
}

I don't think we want to increase complexity by explicitly supporting a peerRange property.

3. Currently with dep-check 1.0, if a profile is given in the dep-check command, that would be used for alignment for the dependencies defined in the profile. But if dependencies like react/react-dom/react-native are missing in the profile, the global(Github) 0.64 profile is getting used for alignment. I think this would be changed in dep-check 2.0, as we provide which presets has to be used for alignment, isn't it?

With 2.0, you can have either behaviour, depending on your configuration. If you don't set presets, you'll be using one of the built-in presets. This is similar to 1.0 without the use of custom profiles. presets: ["microsoft", "my-custom-preset"] is roughly equivalent to 1.0 with custom profiles. New with 2.0 is that you can provide multiple presets and/or drop the built-in preset entirely.

4. In dep-check 1.0 we cant mention more than one profile, but with dep-check 2.0 we can align with more than one profile with "requirements" as an array, isn't it?

requirements is what decides which profiles gets applied. It follows the same rules as reactNativeVersion and reactNativeDevVersion of 1.0 today. These two props currently assume you want react-native. requirements is the generic version of them.

5. With dep-check 2.0, we should be able to call/define a profile with any string eg: "default-profile", right? Cause in RFC proposal I see every requirement is based out of a dependency with a version eg: react@^18.0 / core@0.66. Can I define a profile irrespective of a dependency, declare the dependencies of my interest to be aligned in a single profile and use it for alignment on all of the packages?

Profile names no longer matter in 2.0. Not unless you are looking to overwrite profiles.

[tido64]

@afoxman, @AlekhyaYalla, @dzearing, @JasonVMo: We've incorporated all your feedback and made some sections clearer. Please have a look and sign off if you have no further comments/questions.

[afoxman]

Thank you for all the hard work and responsiveness on this RFC. This RFC is approved.

Next step is to enter a 7-day comment period. Since the community has already been commenting for several weeks, I think approval from the ppl CC'd in the last comment is enough to constitute final acceptance.

After that, please create and bind a new "implementation" issue to it. That issue will be tagged in any PRs where code is submitted to the repo. When all PRs are done and the work is finished, you can close the issue and consider the RFC complete.

[afoxman]

Congratulations @tido64 and @kelset on having your RFC accepted and approved!

[kelset]

the issue tracking existing work is here: #1890