[x-license] Getting "MUI X: License key expired" while using a legit key

[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.