[code-infra] Prepare publishing @mui-internal/typescript-to-proptypes to npm

[michaldudak]

Prepare publishing the internal typescript-to-proptypes package and its dependency, docs-utils to npm.

Changes included:

• Renamed typescript-to-proptypes to @mui-internal/typescript-to-proptypes.
• Renamed @mui-internal/docs-utilities to @mui-internal/docs-utils (to follow the pattern we use in other projects).
• Moved the getPropsFromComponentNode function from api-docs-builder to docs-utils, as it's used by multiple projects.
• Set up typechecking and build for both projects.

In the Core repo, these projects are referenced from source, as before.

MUI X integration PR: mui/mui-x#11801

[mui-bot]

Netlify deploy preview

https://deploy-preview-40842--material-ui.netlify.app/

Bundle size report

No bundle size changes (Toolpad)
No bundle size changes

Generated by 🚫 dangerJS against 076f99f

[Janpot]

I'm good with this if mui/mui-x#11801 passes

[oliviertassinari]

This package was released 3 days ago https://www.npmjs.com/package/@mui-internal/docs-utils.

@michaldudak Could we:

1. Remove all the members in https://www.npmjs.com/settings/mui-internal/members. I don't have admin permissions to do it. This should be enough to not silently fail.
2. Rename all of these to @mui/internal-*
3. npm deprecate the @mui-internal/* packages
4. Isolate the @mui/internal-* packages to the Material UI, Joy UI, Base UI, MUI System npm packages. We need to publish the former for each commit, and the latter once a week. So it seems to me that two should be released with two different scripts. It's also relevant to isolate npm permissions.

[michaldudak]

Hi, yes, that's the plan.

Isolate the @mui/internal-* packages to the Material UI, Joy UI, Base UI, MUI System npm packages.

As far as I know, lerna version does not support filtering, so having these packages in the same repo may force us to release on the same schedule as the public Core packages. We could write a custom script that resets their version after lerna version finishes, but it may be confusing for the person releasing the packages.
One solution I can think of would be moving these packages to a separate infra repository and setting up different release rules there. If we used conventional commits, we could automate the most (if not whole) part of the release process, including the changelog generation. What do you think?

cc @Janpot

It's also relevant to isolate npm permissions.

Do you think about restricting who can publish the infra packages?

[Janpot]

If the goal is to develop the docs package in conjunction with the core libraries then I think following the core packages release schedule is the only option. The docs package has a dependency on the core packages, if they live in the same monorepo, it will depend on an unreleased version of the core packages in the monorepo. Any release of the docs package that is separate from a release of the core packages will potentially depend on unreleased changes in core packages and be broken. This is not a new problem, we already run into this with the current setup. Just last month alone monorepo update in X was blocked at least twice for several days just because it had to wait for core packages to be released. We can develop infra in a separate repo, but it takes away the ability to develop core and docs together.

And so here's where the submodules approach potentially could benefit us, bringing core modules + docs module together in the X monorepo and you act as if X+core is one big pnpm workspaces.

[oliviertassinari]

Just last month alone monorepo update in X was blocked at least twice for several days just because it had to wait for core packages to be released

Oh, I didn't know this, but it makes sense, we are dogfooding new MUI System and Material UI APIs on the docs infra.

submodules approach

I was going to raise this, it's a new argument in the "pros" side.

But it feels like we could with some hacks release the infra packages more frequently than the product ones, and that the reliance on the release of the product packages is temporary, or that we could solve it with canary versions (under a different npm name to not clutter the npm version view).

It feels like it will be harder for MUI System team to dogfooding if we move the infra to the mui-public repository.

---

For context,

• I landed here from [material-ui] v5.15.11 still not available on npm after few days, but dependencies are #41260 (comment).
• I'm pushing so we move to monthly releases for the product packages, with canary on the side.

[michaldudak]

I agree, this could be an issue with docs infra packages as they rely heavily on Core projects. The code infra packages, however, don't (or they are about to be decoupled), and could be released any time.

[Janpot]

But it feels like we could with some hacks release the infra packages more frequently than the product ones, and that the reliance on the release of the product packages is temporary, or that we could solve it with canary versions (under a different npm name to not clutter the npm version view).

This will be very tricky for X (and Toolpad), because the X packages rely on published releases of core packages. If the docs rely on docs infra which relies on canary releases, then we end up with two versions of core packages in the docs.

edit: I assumed docs package being an infra package, but rereading your comment, that's probably not what you meant