[x-license] Multiple version support

[RahavLussato]

The problem in depth

Hello, we renewed our license for MUI X, we got a new key “624ef......”, when I update our mui x data grid pro
we get a placeholder of “MUI X: License key expired” when we use the components.
previously we used @mui/[email protected] and I did an upgrade to "@mui/x-data-grid-pro": "^5.15.0".
when I upgrade to the latest I get "MUI X: Expired package version",
I've tried setting the license using "@mui/x-license" and also "@mui/x-license-pro" which did not work.

Your environment

No response

Search keywords: License key expired

Order ID: 103279

Context

https://mui.zendesk.com/agent/tickets/24626

[RahavLussato]

When debugging the licenseInfo object you can see that although we set it with key "62...", when it tries to get the key for verification it gets a weird key of "65...."

[RahavLussato]

[RahavLussato]

for now rolling back to "@mui/x-data-grid-pro": "5.17.5" works.

[oliviertassinari]

Thanks for opening a Zendesk ticket, I propose we continue this thread there https://mui.zendesk.com/agent/tickets/24626, until we find if there is a root cause or not in the code. We will report the solution here for future developers, to continue to build up a knowledge base.

---

Off-topic. Fun observation on this:

• We use @mui/x-license as a dependency

  mui-x/packages/x-charts-pro/package.json

  Line 47 in 758d8b8

  "@mui/x-license": "workspace:*",

• But we also use it as a singleton:

  mui-x/packages/x-license/src/utils/licenseInfo.ts

  Line 22 in 758d8b8

  return ponyfillGlobal.__MUI_LICENSE_INFO__;

This is bound to fail, one day or another. It won't work if a developer uses two versions of an MUI X component because he's migrating from one to another or adding a new one while not migrating an old one and we changed the way the license key structure (needed one day or another). We only have a few options:

1. We don't allow progressive migration on the same page. This wouldn't be great. It pretty much feels like the current state of things. Progressively migration isn't truly supported.
2. We make it so that license key logic is always backward compatible (it's impossible to guarantee to be always future-proof). We have done this so far. This would mean that someone could add a brand new component, by updating @mui/x-license. Now, the problem is that for this to work, we can't simply have this package as a dependency:

mui-x/packages/x-charts-pro/package.json

Line 47 in 758d8b8

"@mui/x-license": "workspace:*",

Hence why we are on 1. Now, we could make changes to make it work is:

• 2.a When using setLicenseKey() from the component npm package itself, it doesn't use any singleton, it scopes it to local values. If there is any kind of npm package duplication, it stops working. The use case can be micro-frontend or as an escape hatch.
• 2.b When using setLicenseKey() from the @mui/x-license package, we have a global variable (like today)

3. A variation of 2. where in 2.b instead of a single global variable, we store the license keys in the global variable based on releaseInfo. This way, we can set multiple of them, and components can retrieve the oldest most recent release info, relative to their own release info.
   This might be overkill. Maybe 1. is just fine, if not 2. 3. is kind of a last resort.

[flaviendelangle]

We don't allow progressive migration on the same page. This wouldn't be great. It pretty much feels like the current state of things. Progressively migration isn't truly supported.

This is indeed the current state. We started with the grid and never trully removed the singleton.

[cherniavskii]

I believe LicenseInfoProvider is the solution to the singleton issue:

mui-x/packages/x-license/src/useLicenseVerifier/useLicenseVerifier.test.tsx

Lines 74 to 76 in a5f4a73

	<LicenseInfoProvider info={{ key }}>
	<TestComponent />
	</LicenseInfoProvider>,

Jan added it for Toolpad's needs, so we never documented it.

[oliviertassinari]

It's a exposed as unstable. I'm not sure it would help here though. The React context is hosted in a separate package than the component. So people needs to install multiple versions of the license package, which seems hard to figure out which version to install.

[flaviendelangle]

The React context is hosted in a separate package than the component. So people needs to install multiple versions of the license package, which seems hard to figure out which version to install.

Or we would need to have all the package the person use be compatible with a shared version of the license package.

I have a side question that I think is related: how do we want to version the license package once we have a MUI X package (that will be in v9, v10 etc...) and a Base UI X package (that will be in v1, v2, etc... if I understand correctly).
Or do we plan to have 2 license packages? One for MUI X and one for Base UI X?

If we need to decouple the version of the license package with the version of the commercial product packages, then maybe we should just avoid BCs at all cost on it.
We would have a @new-company-name/license package that would be in v1 for several years, and the day we absolutely need to update to a v2, we would make sure this v2 is still compatible with as many previous major versions as possible to make sure everybody can always use a single version of the license package.

Not saying that it's ideal of course 😬

[oliviertassinari]

How do we want to version the license package once we have a MUI X package (that will be in v9, v10, etc...) and a Base UI X package

I think it should be a singular package, from the @newco/x-license npm org space. Separate versions relative to Base UI and MUI. It seemed that it would be the simplest. The rationale:

• no duplication until we find a strong reason to, one of my general operating principles.
• aligned with what people want: simplicity of the setup. I think it's almost guaranteed that developers will use Base UI and MUI in their codebase. Take a sample of 100 projects, and it should be already clear that 80%+ already do (though different project names).
• aim for unified pricing, simpler, also reduce friction around churn (MUI > Base UI is the likely path as the user journey matures).

[flaviendelangle]

I think it should be a singular package, from the @newco/x-license npm org space

I agree with you

In which case, this package won't automatically have its major version synchronized with the MUI X and Base UI X commercial packages.

This does not solve our pain point automatically of course. To do that we would need to make sure @newco/x-license have very little major and that our commercial packages are compatible with the old and the new major version of @newco/x-license for some time to allow for a smooth migration.

I'm not a fan of introducing a new version synchronization topic but I don't see how to avoid it 😬