-
-
Notifications
You must be signed in to change notification settings - Fork 32.4k
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
[core] Use Lerna to publish #23793
[core] Use Lerna to publish #23793
Conversation
9225c33
to
52ad2e8
Compare
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.
What are all the changes to the tsconfigs for?
"release": "yarn build:release && lerna publish --no-changelog --dist-tag next --contents build", | ||
"publish:dry-run": "lerna publish --no-changelog --dist-tag next --contents build --no-git-tag-version --no-push --registry=\"http://localhost:4873/\"", |
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.
Could you add some docs to the release process while we're at it? It's unclear how this should be used.
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.
Sure, I would be happy too. The objective of the dry-run
command was to test that the release process works end-to-end. I have used https://github.com/verdaccio/verdaccio.
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.
Could you add some docs to the release process while we're at it?
Done https://trello.com/c/H7Tz29ft/2763-release-steps. It's almost identical to the release steps of Material-UI X.
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 meant documenting as in adding a section to CONTRIBUTING.md so that we can always keep it in sync.
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 think that moving it to git would have the opposite effect, it will make updating the instructions more painful (opening a PR vs. doing the edits directly), so more likely to go out of sync. I think it's why the GitHub Wiki is using a different edit workflow tradeoff. Many of the steps are not directly related to the code. But happy to give it a try if you think it's important.
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.
(opening a PR vs. doing the edits directly),
I suspected that you're less and less interested in having your work reviewed. But you seem to be doing fine with just committing if you don't want people to review it. Why would that not work here?
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.
it will make updating the instructions more painful
Then we need to work on the pain points when opening a PR. What are frequent problems you run into?
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 think that keeping in sync and helping with reviews are two different topics. I thought the concern was with keeping in sync with the code.
I had assumed that we wouldn't need to review changes to the release workflow instructions, that they are meant to be an unbiased list of steps to follow, that if there is a mistake in it, anybody would go and update the instructions to fix them.
I had also assumed that reviewing the release workflow would require a different discussion. I'm still happy to do it if you think it's important. React has it documented in git: https://github.com/facebook/react/blob/master/scripts/release/README.md.
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 had assumed that we wouldn't need to review changes to the release workflow instructions, that they are meant to be an unbiased list of steps to follow, that if there is a mistake in it, anybody would go and update the instructions to fix them.
Same exact reasons why we keep any documentation checked-in. The release workflow isn't something special that needs to be kept in a separate, inaccessible place. At least I can't see a reasons from what you've told. Maybe there are other factors you're not sharing but I can't address those.
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 have moved the content of the Trello card to a readme.
@@ -1,5 +1,4 @@ | |||
{ | |||
"packages": ["packages/*", "docs", "framer"], |
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.
Has no effect, useWorkspaces
override it.
@eps1lon There are a couple of different changes in the |
So can we handle this another time then? It sounds like the tsconfig changes are not blocking any step in the release process. Unless you're doing something difference, hence the request to add documentation. |
Could you please describe the steps that are breaking? First you said it was If it's only |
Well nobody can help you if you don't ask and silently commit to the repo. The CI is not for certain groups only. It helps everyone so please leverage it instead of skipping it. This can leave the repository in a broken state that nobody is aware of. |
A cleaner reproduction:
git clone [email protected]:mui-org/material-ui.git foo
cd foo
yarn
cd packages/material-ui/ && yarn build
cd ../packages/material-ui-lab/ && yarn build && cd ../../
cd packages/material-ui/ && yarn build
That wasn't "clean", agree. Hopefully, the change was small enough to be easy to revert. |
Perfect, it's already reproducible with just repeating Update: Fixed by |
Should be rebased on |
ddb808e
to
4e8e697
Compare
07b2df8
to
4b8373f
Compare
6c41c0d
to
1b970ab
Compare
1b970ab
to
c2ac558
Compare
Closes #23785. The usage of Lerna should solve the pain around managing the version between the different packages. I have been doing it by hand so far. However, it's error-prone, doesn't scale with the number of packages, and time-consuming.