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

Bolt publish fails because npm can give wrong information quite often #205

Open
lukebatchelor opened this issue Nov 9, 2018 · 1 comment

Comments

@lukebatchelor
Copy link
Member

Through no fault of this project, bolt publish can still fail when npm has data replication issues.

We are now seeing this issue tens of times a day in the atlaskit-mk-2 repo.

Scenario

  • A package is published (e.g [email protected])
  • Later than day bolt publish is run to release any unrelased packages.
    • bolt runs npm info for each package in the repo to find which are ahead of npm
    • npm says that the latest version of pkg-a is 1.0.0
      • local version is 1.0.1 so bolt marks it as ready to release
    • bolt attempts to publish [email protected]
    • npm returns a 403 as you cannot published over an already published version.

Suggested fixes

  1. We could look for another source of truth for which versions have been deployed. Unfortunately:
  • npm info can be wrong
  • yarn info can be wrong
  • unpkg can be wrong (but is correct more often than npm info)

🚫So this likely wouldn't solve the problem (unless there is a better source of truth)

  1. We could look at the error messages that come back from npm and ignore them if they are 403's with the message saying you cant publish over an existing version
  • ✅ moderately safe, since we know there must be a mistake on npm side since we must have just run and npm info which gave us conflicting info
  • 🚫 feels slightly risky as it's ignoring what could be a legitimate error (race condition in a package being released in two places at once).
    • Not possible in atlaskit, but possible in other places?
  1. We could change the way publish works and take an explicit list of packages to publish and ignore the others
  • 🚫 This would remove some of our auto-recoverability which would need to be solved another way
  • 🚫 Would be a breaking change to current

Personally, I'd lean towards option 2. Happy to put it behind a flag if necessary though.

Thoughts?

@lukebatchelor
Copy link
Member Author

CC @jamiebuilds

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant