-
-
Notifications
You must be signed in to change notification settings - Fork 32.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[code-infra] Prepare publishing @mui-internal/typescript-to-proptypes to npm #40842
Merged
michaldudak
merged 6 commits into
mui:master
from
michaldudak:npm-publishing/typescript-to-proptypes
Feb 2, 2024
Merged
Changes from all commits
Commits
Show all changes
6 commits
Select commit
Hold shift + click to select a range
218c38d
Publish @mui-internal/docs-utils to npm
michaldudak f9dffaa
Publish @mui-internal/typescript-to-proptypes to npm
michaldudak 0a1db7b
Exclude tsbuildinfo from package contents
michaldudak 86c5193
Add access: public to packages
michaldudak cbf67a3
Bump TTP version
michaldudak 076f99f
Bump TTP version
michaldudak File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
2 changes: 1 addition & 1 deletion
2
docs/src/modules/components/ApiPage/sections/ClassesSection.tsx
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file was deleted.
Oops, something went wrong.
This file was deleted.
Oops, something went wrong.
This file was deleted.
Oops, something went wrong.
This file was deleted.
Oops, something went wrong.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1 @@ | ||
.tsbuildinfo |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,5 @@ | ||
# Changelog | ||
|
||
## 1.0.0 | ||
|
||
Initial release as an npm package. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,9 @@ | ||
# @mui-internal/docs-utils | ||
|
||
This package contains utilities shared between MUI docs generation scripts. | ||
This is an internal package not meant for general use. | ||
|
||
## Release | ||
|
||
1. Build the project: `pnpm build` | ||
2. Publish the build artifacts to npm: `pnpm release:publish` |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,30 @@ | ||
{ | ||
"name": "@mui-internal/docs-utils", | ||
"version": "1.0.0", | ||
"author": "MUI Team", | ||
"description": "Utilities for MUI docs. This is an internal package not meant for general use.", | ||
"main": "./build/index.js", | ||
"exports": { | ||
".": "./build/index.js" | ||
}, | ||
"types": "./build/index.d.ts", | ||
"repository": { | ||
"type": "git", | ||
"url": "https://github.com/mui/material-ui.git", | ||
"directory": "packages/docs-utils" | ||
}, | ||
"scripts": { | ||
"prebuild": "rimraf ./build", | ||
"build": "tsc -b tsconfig.build.json", | ||
"typescript": "tsc -b tsconfig.json", | ||
"release:publish": "pnpm publish --tag latest", | ||
"release:publish:dry-run": "pnpm publish --tag latest --registry=\"http://localhost:4873/\"" | ||
}, | ||
"dependencies": { | ||
"rimraf": "^5.0.5", | ||
"typescript": "^5.1.6" | ||
}, | ||
"publishConfig": { | ||
"access": "public" | ||
} | ||
} |
File renamed without changes.
Oops, something went wrong.
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This package was released 3 days ago https://www.npmjs.com/package/@mui-internal/docs-utils.
@michaldudak Could we:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi, yes, that's the plan.
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 afterlerna 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
Do you think about restricting who can publish the infra packages?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, I didn't know this, but it makes sense, we are dogfooding new MUI System and Material UI APIs on the docs infra.
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,
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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