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 pkg-a@1.0.1)
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 pkg-a@1.0.1
npm returns a 403 as you cannot published over an already published version.
Suggested fixes
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)
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?
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.
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
bolt publish
is run to release any unrelased packages.npm info
for each package in the repo to find which are ahead of npmpkg-a
is1.0.0
pkg-a@1.0.1
Suggested fixes
npm info
can be wrongyarn info
can be wrongnpm info
)🚫So this likely wouldn't solve the problem (unless there is a better source of truth)
npm info
which gave us conflicting infoWe could change the way publish works and take an explicit list of packages to publish and ignore the others
Personally, I'd lean towards option 2. Happy to put it behind a flag if necessary though.
Thoughts?