Overriding external mismatch rule

[emmatown]

Should people be able to override it?

What does configuring it look like?

[Noviny]

Should people be able to override it?

Use-case:

In projects that are large enough, upgrading a package may require changes to a very large surface area. individuals or teams within the project may not have the visibility to bump+test all uses of a package. This creates drag, where no team can bump a package version of anything.

External mismatches can allow you to upgrade across a system incrementally.

What does configuring it look like?

Less 'what it looks like' but more some design goals:

• Exceptions should be, well, the exception. You should have to actively put yourself in an exceptions state.
• Exceptions should be easy to find + monitor for the repository owner.
• (Most) exceptions should be temporary in nature - with the intent of it being a temporary measure.
• exceptions shouldn't experience a lot of churn (this is an assumption about their usage)
• These assumptions should be enforced/discoverable within the project

Now going to answer some things about the shape:

---

Formatting

The needed bits of information are:

• external package name
• internal packages where it is an exception
• 'expiry date' for the exception

NB: I don't think any version info needs to be held with the exception - exceptions are whatever, and the latest will be consistent across other packages.

This leads to an exception looking something like:

{
  "packageName": "button",
  "internalPackages": ["pkg-a", "pkg-c"],
  "expiresOn": "YYYY-MM-DD"
}

There are ~ two places you can put this: In a special config file just for holding and tracking these, or in the root package.json file. I vaguely prefer the ideas of putting these in the root package.json, but I'm not 100% on that, as 200 lines of exceptions (unlikely but possible) would be AWFUL.

manyPkg helpers

(oh no what am I doing creeping this complexity)

command to add an exception

yarn manypkg exception packageName pkg-a,pkg-b

command to list exceptions in order of expiration date

yarn manypkg exception list

the wording here is super meh because exception list sounds like the name of a thing but 😕

Thing this design is weird about.

Say I have two packages with a react-select exception, and I want them to expire at different dates - does that work? Does it work by just having two entries in the array both specifying react-select? What's the CLI process for adding this for two packages at different dates or does it just end up being manual?

[Noviny]

(turns out I was carrying a lot of thoughts on this)

[emmatown]

'expiry date' for the exception

What happens after this expiry date? Should manypkg check fail? If so, wouldn't we have a big problem where nothing can be merged because CI will fail everywhere?

There are ~ two places you can put this: In a special config file just for holding and tracking these, or in the root package.json file. I vaguely prefer the ideas of putting these in the root package.json, but I'm not 100% on that

I think the root package.json is the right place.

200 lines of exceptions (unlikely but possible) would be AWFUL.

I think that it being AWFUL and painful if overused is arguably a good thing so that people are discouraged from overusing it.

[Noviny]

What happens after this expiry date? Should manypkg check fail?

This is a reasonable question. I think it's meant to fail CI (it forces an upgrade time) - possibly you could make it output error logs but not be 'failing' - which is counter-intuitive but surfaces it to devs locally without breaking everything.

The alternative is, I guess either not including a date, or make a special date-surfacing check basically just so maintainers can go through and harangue contributors when it's passed - which doesn't sound fun as a project maintainer.

---

I think that it being AWFUL and painful if overused is arguably a good thing so that people are discouraged from overusing it.

🎉🎉🎉 agreed

[emmatown]

Maybe for a first implementation, we should exclude expiresOn and revisit it later?

Naming nits:

  "dependency": "button",
  "packages": ["pkg-a", "pkg-c"],

[Noviny]

Seems good. Shall we declare this a spec and then probably not do it immediately?

[emmatown]

One last thing that we haven't defined that we should define, what's the name of the field in the package.json. exceptions? Is that too generic of a name?

Other than that, declaring this a spec and probably not doing it immediately SGTM.

[Noviny]

I dislike exceptions

"manypkg": {
  "exceptions": []
}

is probably my preference.

[emmatown]

SGTM

[marcodejongh]

External mismatches can allow you to upgrade across a system incrementally.

We would like this feature! And wouldn't mind building it. But it would also need to include the version though, for example:

   "externalMismatchOverrides": {
      "react": "2.0.0"
    }

When we're upgrading a large repo incrementally, we still want to avoid other versions being introduced besides the current + next version.

What's the API we'd want?

"manypkg": {
  "exceptions": [
     { 
        "dependency": "button",
        "packages": ["pkg-a", "pkg-c"],
     }
   ]
}

Why would we want to scope the exception to particular packages? Isn't it safe to assume the whole repo will eventually want to be upgraded? If we make that assumption, the packages array only adds an extra hurdle. So maybe for MVP it could be:

"manypkg": {
  "exceptions": [
     { 
        "dependency": "button",
        "versionSpecifier": "^2.0.0"
     }
   ]
}

Also, when running fix, manypkg will accept the exception or the most common. If the version is neither exception nor most common, it'll fix to most common.