Skip to content
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

Can't publish with uncommitted changes when bumping "from-package" #2550

Closed
arizonatribe opened this issue Apr 18, 2020 · 2 comments
Closed
Labels

Comments

@arizonatribe
Copy link

arizonatribe commented Apr 18, 2020

Expected Behavior

If I'm bumping from patch , for example, I can force it to publish a package even though there are uncommitted (git) changes in the repository. This is the same with any of the other bump options except for from-package.

Current Behavior

If you change the bump type from one of the ones supported by version to the ones supported by publish, some of the version flags are not being honored. There seems to be a bit of code commenting in the lerna/commands/publish/index.js indicating there is an optimistic attempt/hope that the from-package will work without git (but no guarantees). However I believe this one is a fairly simple fix.

Possible Solution

I don't personally know the history and use of many of the flags, so I don't want to dictate the best solution.

But I noticed these lines in the lerna/commands/publish/index.js:

    // attempting to publish a release with local changes is not allowed
    chain = chain
      .then(() => this.verifyWorkingTreeClean())

However in the lerna/commands/version/index.js the logic is a bit different:

    // amending a commit probably means the working tree is dirty
    if (this.commitAndTag && this.gitOpts.amend !== true) {
      const { forcePublish, conventionalCommits, conventionalGraduate } = this.options;
      const checkUncommittedOnly = forcePublish || (conventionalCommits && conventionalGraduate);
      const check = checkUncommittedOnly ? checkWorkingTree.throwIfUncommitted : checkWorkingTree;
      tasks.unshift(() => check(this.execOpts));
    } else {
      this.logger.warn("version", "Skipping working tree validation, proceed at your own risk");
    }

My thought/suggestion is to make it so that the throwIfUncommitted in the publish command is (somewhat) similar to the logic in the version command. Is it possible to inspect the options in the publish command (since it honors those from version) and see if one of those (such as forcePublish) is provided before throwing that error?

Steps to Reproduce (for bugs)

Make some local changes and then attempt to run a lerna publish from-package --no-git-reset --no-push --no-git-tag-version --force-publish

You can also try that same command, but change from-package to some other bump option (like patch)

{
  "packages": [
    "packages/*"
  ],
  "version": "independent"
}

Context

Noticed it today. I'm trying to create a publish script that will work in both a CI/CD environment and during local development into a local registry (ie, verdaccio). The multi-package repo I'm working on has a mix of NPM packages and several APIs (all marked as private: true).

Sometimes an author of one of those APIs wishes to build the associated docker container for that API, and so we can make that work by first publishing the un-published NPM packages into a local registry (using the same publish script we use for publishing to the real registry, but fed a local registry URL instead). That way they can know before merging branches into develop/master that their API is going to build.

We are 99% of the way there and the only hang-up at the moment is having to force all the package publishes to be patch instead of relying on the way we prefer (to manually set them in the package.json files themselves).

To be clear though, this isn't a docker issue and I'm not looking for nor do I need any docker support or compatibility. I'm just looking for the git uncommitted changes to be able to be ignored for from-package as they can be for patch / minor , etc.

Your Environment

lerna 3.20.2
node >= 11.0 < 13.0
Mac and Linux

@github-actions
Copy link

github-actions bot commented Jun 3, 2022

Hi Folks 👋

You may or may not know that lerna is now under the stewardship of Nrwl (announcement here #3121), a company with a long history of not just producing valuable open-source software (OSS), but also backing others (at the time of writing, Nrwl has donated over $50,000 to OSS it hasn't created, see https://opencollective.com/nx for full details).

Quite simply, Nrwl ❤️ OSS, and is committed to making lerna the best it can be. We use it ourselves.

In order to take this awesome project forward from its current state, it is important that we focus our finite resources on what is most important to lerna users in 2022.

With that in mind, we have identified this issue as being potentially stale due to its age and/or lack of recent activity.


Next steps:

We want to give you some time to read through this comment and take action per one of the steps outlined below, so for the next 14 days we will not make any further updates to this issue.

@arizonatribe as the original author of this issue, we are looking to you to update us on the latest state of this as it relates to the latest version of lerna.

Please choose one of the steps below, depending on what type of issue this is:

  • A) If this issue relates to a potential BUG in the latest version of lerna:

  • B) If this issue is a FEATURE request to be added to the latest version of lerna:

    • Simply comment back on this thread so that we know you still want us to consider the request for the latest version of lerna.
  • C) If this issue is a QUESTION which is applicable to latest version of lerna:

  • D) If this issue is no longer applicable to the latest version of lerna:

    • Please close the issue.

If we do not hear from @arizonatribe on this thread within the next 14 days, we will automatically close this issue.

If you are another user impacted by this issue but it ends up being closed as part of this process, we still want to hear from you! Please simply head over to our new issue templates and fill out all the requested details on the template which applies to your situation:

https://github.com/lerna/lerna/issues/new/choose

Thank you all for being a part of this awesome community, we could not be more excited to help move things forward from here 🙏 🚀

@github-actions
Copy link

Hi Folks 👋

You will have seen in our message above that we at Nrwl are working really hard to bring the lerna repo up to date with what matters most to its community in June 2022.

As previously stated in that message, because we have not heard from the original author of this issue within the last 14 days, we are now automatically closing it.

If any users, including the original author, are still impacted by this issue then we still want to hear from you!

All we ask is that you first update to the latest lerna (5.1.4 at the time of writing) to make sure it is still reproducible, and then fill out one of our new issue templates, providing all the requested details which apply to your situation:

https://github.com/lerna/lerna/issues/new/choose

Many thanks again! 🙏


P.S. Over and above getting to grips with the repo, we have also been hard at work launching a new website, resolving all vulnerabilities, merging exciting new features and reigniting community PR contributions! 🚀

You can read our recent blog post to learn more about what we've been up to:
https://blog.nrwl.io/lerna-5-1-new-website-new-guides-new-lerna-example-repo-distributed-caching-support-and-speed-64d66410bec7

@github-actions github-actions bot locked and limited conversation to collaborators Jun 17, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

1 participant