RFC: Improving lerna publish
#1767
Comments
|
+1 to separating versioning from publishing. In our lerna workflow many developers work on the various packages but very few have privileges to publish. This creates a situation where the publisher needs to know at publish time how to version a component. The developer pushing changes should know how their changes affect the version and ideally would be able to indicate that prior to publish time. Secondly separating versioning from publishing would allow us to create an automated job to publish the packages. No versions choices would need to be made at publish time. |
|
@mjhenkes It's important to note that versioning ( |
This was actually the default in early lerna 2.x, it would first publish to a Should it be restored as the default? I'm not against it, I suppose. We still need to do better "disaster recovery," in any case. Temporary dist-tags aren't going to solve the entire problem (not that you were implying that).
Big 👍 |
|
On
I'd say I'd also say that there should not be an implicit (or any other) usage of
Is there a reason it was moved to be non-default for lerna 3.x? |
|
For the record, we dicussed publishing flow improvments today (November 13th) during weekly WordPress core JavaScript chat (you can also check chat transcript for more details). We also track the same issue in the Gutenberg repository: WordPress/gutenberg#11780. In this repository we maintain source code of all npm packages published under WordPress organization.
At the moment we defer to Lerna performing version increments for all packages. We only express our intent for the change inside of the corresponding changelog files when working on PRs. The biggest downside of this approach is that we need to scan all existing changelog files during publishing and re-apply manually the proper version bump for each package. It would be a nice improvement if we could update both changelog and There is also this issue that some packages get updated only because they depend on other updated packages. This is where Lerna is the most helpful because it's almost impossible to detect it manually when you have to maintain 50 packages with independent versioning. It might what One thing which didn't work well in the past is pushing publish commit. It takes some time to provide all version increments and publish all packages. We had the case where new commit was pushed to |
In the past, we had publish failures caused by 2FA timeout where we had more packages to publish than it could be handled in 30 seconds. The following steps don't quite work well in the majority of cases to recover from such failure:
It's tons of manual work and we had 2 releases where we published local paths inside "@wordpress/autop": "file:../autop",
"@wordpress/blob": "file:../blob",
"@wordpress/blocks": "file:../blocks",
"@wordpress/components": "file:../components",
"@wordpress/compose": "file:../compose",
...I don't have enough technical knowledge to propose a proper solution inside Lerna. However, I'm happy to discuss all possible improvements in the flow on a higher level. If we agree on the future steps and will have a list of tasks to work on, we will try to help find volunteers to implement them. We plan to discuss publishing packages again next week. For us, the most pressing part is having a reliable way to publish to npm using 2FA enabled for publishing. |
|
What I'm wondering is, and will test later, is if the following workflow is a valid way of publishing packages:
The above workflow would remove all the manual tasks out of the publish workflow, it would be no guarantee that |
|
I'm really in favor of the version/publish split, as it would help automate releases a bit. In some of the current projects at my employer, we're utilizing Yarn workspaces + semantic-release + semantic-release-monorepo (which is very hacky) to automate releases based on commit messages... which works, but is also problematic. If this could be automated via Lerna, we could forego the semantic-release process and embrace Lerna 100%. Even more so if there were some hooks to update changelog, generate GH releases, etc. |
|
It can already be automated by lerna, just do two tasks or a pipeline of "lerna version" and "lerna publish from-git"; I'm simply saying from-git should be the only path in lerna publish.
… On 4. Dec 2018, at 19:27, Miles Johnson ***@***.***> wrote:
I'm really in favor of the version/publish split, as it would help automate releases a bit. In some of the current projects at my employer, we're utilizing Yarn workspaces + semantic-release + semantic-release-monorepo (which is very hacky) to automate releases based on commit messages... which works, but is also problematic.
If this could be automated via Lerna, we could forego the semantic-release process and embrace Lerna 100%. Even more so if there were some hooks to update changelog, generate GH releases, etc.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
Incremental progress toward #1767 * libnpmaccess -> libnpm/access * npm-lifecycle -> libnpm/run-script * npm-package-arg -> libnpm/parse-arg * npmlog -> libnpm/log * pacote.manifest -> libnpm/manifest * pacote.packument -> libnpm/packument * manually hoist find-up@3
Incremental progress toward lerna#1767 * libnpmaccess -> libnpm/access * npm-lifecycle -> libnpm/run-script * npm-package-arg -> libnpm/parse-arg * npmlog -> libnpm/log * pacote.manifest -> libnpm/manifest * pacote.packument -> libnpm/packument * manually hoist find-up@3
This is done as of v3.7.0 (v3.7.1 improved the logging a bit) |
Proposal for the future of lerna publish:
lerna versionfirst insteadlerna publishand removes functionality that’s duplicated betweenlerna versionandlerna publishThese are my initial thoughts, and I’m definitely interested to keep discussing these to inform development decisions.
The above list is based on some private conversation with various people, and opens up doors for future developments or improvements whilst greatly simplifying the codebase.
The text was updated successfully, but these errors were encountered: