RFC: Proposal for new configuration scheme for dep-check

[tido64]

Goals

• To make it easier to relate to profiles, especially for web only consumers
• To make it easier to provide custom presets (collection of profiles)
  • This used to be hidden from the public, but will be exposed in this proposal. One example of a preset is the built-in one.
• The old configuration scheme will still be supported and take precedence

Motivation

While dep-check is a tech agnostic solution for managing dependencies, its configuration schema is currently very coupled with React Native versions. This makes the configuration look out of place when used in web only packages. Further, users have expressed a desire to centralize their configuration around arbitrary dependencies (e.g. react or @fluentui/react instead of react-native). They also want the ability to bring their own presets.

Proposal

Taking inspiration from browserslist, we want to introduce queries as a way to pick profiles.

For example, to ensure that all packages are aligned on React 18.x:

{
  "dep-check": {
    "requirements": [
      "react@^18.0"
    ]
  }
}

To ensure all packages declare compatibility with React >=16, and align on 18.x for development:

{
  "dep-check": {
    "requirements": {
      "development": [
        "react@^18.0"
      ],
      "production": [
        "react@>=16.13"
      ]
    }
  }
}

You can bring your own presets to enrich the built-in one:

{
  "dep-check": {
    "presets": [
      "microsoft",
      "/path/to/my-collection-of-multiple-profiles"
    ],
    "requirements": [
      "react@^18.0"
    ]
  }
}

Or replace the built-in preset entirely:

{
  "dep-check": {
    "presets": [
      "/path/to/my-collection-of-multiple-profiles"
    ],
    "requirements": [
      "react@^18.0"
    ]
  }
}

You can also add single profiles:

{
  "dep-check": {
    "profiles": [
      "/path/to/additional-profile"
    ],
    "requirements": [
      "react@^18.0"
    ]
  }
}

Note that this config is just a different "frontend" to the tool. Everything else still works the same. For instance, the following configurations are equivalent:

{
  "rnx-kit": {
    "reactNativeVersion": "^0.66 || ^0.67 || ^0.68",
    "reactNativeDevVersion": "0.66",
  }
}

{
  "dep-check": {
    "requirements": {
      "development": [
        "core@0.66"
      ],
      "production": [
        "core@^0.66 || ^0.67 || ^0.68"
      ]
    }
  }
}

Though in this case, you should prefer using rnx-kit since it provides other benefits.

A Note on Conflict Resolution

What happens in the case of conflicts? For instance, React Native is not compatible with React 18 until 0.69. What happens if we require both React 18 and React Native below 0.69:

{
  "dep-check": {
    "requirements": [
      "core@<0.69",
      "react@^18.0"
    ]
  }
}

In this case, dep-check will throw an error since the built-in preset cannot fulfill the requirements. To resolve the conflict, we recommend that users move one of the requirements to the relevant packages. For instance:

// global config
{
  "dep-check": {
    "requirements": [
      "react@^18.0"
    ]
  }
}

// package config
{
  "rnx-kit": {
    "reactNativeVersion": "^0.66 || ^0.67 || ^0.68",
    "reactNativeDevVersion": "0.66",
  }
}

In short, dep-check will not try to resolve conflicts. It is up to users to build presets/profiles that fit their needs.

[kelset]

Personally, I don't think this proposal is something we should pursue. At least, not in this shape.

It introduces a massive degree of freedom that breaks away from the core idea at the heart of dep-check, which is "given a version of RN, make the other known libs be on the right version" - but it tries to do so by expanding beyond what I consider safe boundaries. I can easily see people getting confused by the too many different ways you can have profiles, presets and requirements setup, and that leading to more problems than the ones it solve; de facto, killing the willingness to have such tool in place.

Basically, in my mind, this approach tries to keep the "old/original" concept and stretch it to fit and entire category of different requirements and scopes (monorepos, web) - kind of making the tool try to "juggle too many balls" 🤹‍♀️

If this idea of expanding dep-check into something greater is something we want to pursue, I think we really need to take a step back and rearchitect the entire tool so that all the various approaches are "custom takes" on a strong core idea. Right now it's "RN first, then everything else"; we should come up with a high degree generalization, then fit the various cases (RN, monorepo, web, etc) as "plugins on top". This should then make it easier to use it in a way that is consistent across the board.

[dzearing]

I think if we want dep-check to be a proprietary tool for React Native, we should consider naming it something like rn-dep-check to avoid confusion. Sometimes a more proprietary focus can enable a more tailored experience, but I have some reluctance that's really needed here.

I think if the intent is to generalize it, we should probably still rename it due to conflict with depcheck but I think the config is very interesting and robust. I think it would be a more valuable tool if the same react-native grouped requirements can be represented with a more abstract configuration.

[JasonVMo]

i think the question is what are the user scenarios we are trying to address? I think having web and react-native code in the same repository, with crossover between them is a valid scenario. That is typically true for us internally, but I think it's likely to be true in the community as well. In these mixed scenarios it isn't reasonable for react-native to be the core version dependency around which everything else pivots, which is why adding the ability to add things like react to the mix seems to make sense.

I also tend to think it dangerous to have multiple tools managing dependency versions in the repo. There's of risk of one tool messing up the determinations of the other tool. Dep-check was built because of the challenges in managing versions with react-native, but I do think it is useful for non-react-native scenarios as well. If it were only focused around react-native I think it would become more and more marginalized in our own repos, as other teams would have to develop competing technologies that manage the web side of things.

David, I do agree with the name, as depcheck is a pretty well known tool.

[kelset]

(re: naming - should we reopen this and have that conversation there? #484)

[afoxman]

What might help here is a set of examples of how the core idea of aligning dependencies to a set of constraints plays out in a React Native project, a web project, and a JS tools project. That would give enough diversity to have a conversation about the merits of different config approaches, and how they co-exist when these projects live in the same repo or even the same package.

[afoxman]

And the proposal should suggest a way for package authors to express compatibility with other external packages like "react-native", "react", "node", "webpack", "node", etc.

[afoxman]

How will React Native-specific functions like set-version be handled? Is there a need for "extensions" that plug in additional commands or rules?

[tido64]

How will React Native-specific functions like set-version be handled? Is there a need for "extensions" that plug in additional commands or rules?

I added a sentence about this. Nothing else changes. This essentially provides a second way of configuring dep-check, purely for the benefit of being able to express requirements in terms of other packages than react-native. Code-wise, it also reflects better what happens under the hood, so it's refactoring work that I want to do regardless since it brings better clarity (I hope).

[kelset]

Hey folks, me and Tommy over the last 3 days did a bit of a long-multipart-brainstorm session - I think that we have reached an agreement of how this new version of dep-check, let's call it 2.0, could be shaped.

Here I'll just highlight the main feedbacks that we discussed earlier today, that will make the proposal a bit more solid and lean - and in that way, will make the tool be less RN-centric and more generic (without revolutionising too much from the original proposal from Tommy):

I'll start this off by showing how the config will live in a package.json:

{
  "rnx-kit": {
    "kitType": "app",
    "bundle":{
        ...
    },
    "dep-check": {
        "presets": [
          "microsoft",
          "/path/to/my-collection-of-multiple-profiles"
        ],
        "requirements": [
          "react@^18.0"
        ],
        "capabilities": [
          "core-android",
          "core-ios",
          "core-macos",
          "core-windows",
          "react",
          "test-app"
        ],
        "exclude-packages":{
            "folder-name"
        },
      }
  }
}

and use this to highlight the main feedbacks/changes that me and Tommy discussed in our brainstorming:

• the config will live within the rnx-kit section (not on its own)
• both presets and requirements can't be empty. Better to be explicit.

  • this will also help clarify from where dep-check will pick up the info to use (presets) and which specific profile to get the versions from (requirements)

  • the old way of defining requirements

        "reactNativeVersion": "^0.66 || ^0.67 || ^0.68",
        "reactNativeDevVersion": "0.66",
    

    won't be allowed/valid. It will need to be migrated to the corrispective (just to be clear: the separation of development/production is only valid/needed for libraries - not apps)

    ...
        "requirements": {
          "development": [
            "react-native@0.66"
          ],
          "production": [
            "react-native@^0.66 || ^0.67 || ^0.68"
          ]
        }
      }
    

• no profiles option - it would just add confusion. Also, what we've been calling "custom profile" so far is actually a preset, so the custom preset is expected as an extra element in the presets array.
• the current "default" preset existing in the repo, microsoft will be renamed microsoft-react-native to open the door to have a more generic/web based one such as microsoft-web and similar

---

All of this said, let us know your thoughts and then we can reach a final decision to what the 2.0 version will look like 🤗