[x-license] setting license key in micro frontend

[sag1v]

The problem in depth

Hello, we are using the Pro Plan (including Dates, Data-grid, etc.) and have a Design System package that wraps most of MUI's components with a peerDependency for relevant MUI packages.

Our architecture is centered around Micro-Frontends.
In a simple scenario:

• The App-Frame
• The Page content
• A shared business module

Each of these is bundled independently, having its own React tree. Additionally, they all utilize our Design System, using various MUI components like the ThemeProvider and potentially mui-x-pro components.

One question arises: Is it permissible to execute LicenseInfo.setLicenseKey multiple times on the same page? Upon inspecting the code, it appears that the key is globally stored under the __MUI_LICENSE_INFO__ object.

Moreover, each "mini-app" from the aforementioned list could potentially feature a distinct version of @mui/x-license-pro. Some might even adopt the latest approach as seen in the docs, importing it from @mui/x-license.

Lastly, is it acceptable for each bundle to operate with its own version of MUI and MUI-X-Pro components?

For example:

The AppFrame might have @mui/x-data-grid-pro in version X, while the Page could utilize version Y, and so forth.

Thanks in advance.

Your environment

`npx @mui/envinfo`

``` System: OS: macOS 14.2.1 Binaries: Node: 18.18.0 - ~/.nvm/versions/node/v18.18.0/bin/node npm: 7.24.2 - ~/cloned_projects/fe-ui-core/node_modules/.bin/npm pnpm: Not Found Browsers: Chrome: 127.0.6533.72 Edge: Not Found Safari: 17.2.1 npmPackages: @emotion/react: 11.11.1 @emotion/styled: 11.11.0 @mui/base: 5.0.0-beta.40 @mui/core-downloads-tracker: 5.13.4 @mui/icons-material: 5.11.16 @mui/material: 5.13.5 @mui/private-theming: 5.13.1 @mui/styled-engine: 5.13.2 @mui/styles: 5.13.2 @mui/system: 5.13.5 @mui/types: 7.2.9 @mui/utils: 5.14.18 @mui/x-date-pickers: 6.20.2 @mui/x-date-pickers-pro: 6.20.2 @mui/x-license-pro: 6.10.2 @types/react: 18.2.6 react: 18.2.0 react-dom: 18.2.0 ```

Search keywords: micro frontend multiple license

Order ID

93481

[michelengelen]

This should not be a problem ... at least not that we are aware of it. Safest way to ensure this does not lead to a problem is to wrap the application with the latest license package. Because each instance will override the others before and that could become a problem if you do not constantly update each of your packages. Is that a way for you to handle this?

[sag1v]

Thanks. It would be ideal to always have the latest dependencies, however, this is almost impossible to achieve as some of our pages are pretty complex and involve separate independent modules that are owned by different teams.

Maybe the get/set license method should support (major) versions? For example, the global object could have keys inside objects labeled as the major version:

__MUI_LICENSE_INFO__ = {
  v6: { key: '' },
  v7: { key: '' }
}

This way, you can support multiple major versions on the same page.

I'm worried that our pages will display watermarks to our clients, even though we don't really have a license issue.

[michelengelen]

As long as you don't use v5 anymore this should not pose a problem in any case, since these keys are backwards compatible anyways.

Thanks for the suggestion though. 🙇🏼

I'll close this, but feel free to reopen if you encounter any problems!

[github-actions[bot]]

:warning: This issue has been closed. If you have a similar problem but not exactly the same, please open a new issue. Now, if you have additional information related to this issue or things that could help future readers, feel free to leave a comment.

@sag1v: How did we do? Your experience with our support team matters to us. If you have a moment, please share your thoughts in this short Support Satisfaction survey.

[sag1v]

As long as you don't use v5 anymore this should not pose a problem in any case, since these keys are backwards compatible anyways.

@michelengelen We do have v5 on our pages, but it's in its own bundle (different React tree). We are doing an incremental migration across teams. As I mentioned above, our architecture is based on micro frontends, and on some pages, we have a mix of versions, each in a separate bundle.

What kind of issues might we face?

[michelengelen]

Well, the only issue I could think of is that you might get an error when trying to use a license key that was issued prior to v5.11.0 according to this page in the licensing docs.

Otherwise there should not be a problem, since the keys are backwards compatible

[michelengelen]

I would advice to upgrade the package versions in your frontends or just rely on a single one in the page build.

[sag1v]

trying to use a license key that was issued prior to v5.11.0

When you say "prior to v5.11.0", version of which package are you referring to? @mui/material, @mui/x-date-pickers, @mui/x-date-pickers-pro or @mui/x-license-pro?

[sag1v]

@michelengelen just making sure my last comment 👆 wasn't missed 😃

[michelengelen]

ah, sry ... i am referencing all X packages, but for this the most important one would be the x-license-pro package, since this will effectively check the license!