Auto: npm plugin does not bump the version in package.json

Created on 21 Oct 2020 · 14Comments · Source: intuit/auto

Describe the bug

The package.json is not updated, when running (yarn/npx) auto shipit on a pre-release branch.
(yarn/npx) auto shipit --dry-run --quiet is not reporting the correct version number in that case.
This causes issues downstream as the version number is used to tag docker images and other artifacts.

To Reproduce

Commit on next
auto shipit runs in Github Action
auto released correctly to github
Package json did not update

Expected behavior

Either package.json updates, or auto shipit --dry-run calculates based on tags for prereleases.

Environment information:
"Current version" is wrong here already, the current tag is v0.2.0-next.11

yarn run v1.22.10
$ /home/rwa/Project/####/node_modules/.bin/auto info

Environment Information:

"auto" version: v9.59.1
"git"  version: v2.29.0
"node" version: v14.14.0

Project Information:

✔ Repository:      #####
✔ Author Name:     Robert Wawrzyniak
✔ Author Email:    robert.wawrzyniak@###.de
✔ Current Version: v0.2.0-next.10
✔ Latest Release:  v0.1.0 (https://github.com/####/releases/tag/v0.1.0)

✔ Labels configured on GitHub project

GitHub Token Information:

✔ Token:            [Token starting with 62de]
✔ Repo Permission:  admin
✔ User:             thuringia
✔ API:              undefined (undefined)
✔ Enabled Scopes:   repo
✔ Rate Limit:       4772/5000

Done in 3.39s.
Time: 0h:00m:04s

Additional context
This might be related to #1490 ?

This appears to be by design:
https://github.com/intuit/auto/blob/2f03089f43cc098ac2687c7ab3ca5fd8d2502a1c/plugins/npm/src/index.ts#L869
The bump is only run for base branches here, but there is no config flag to change this.

bug released

Source

thuringia

Most helpful comment

Ah, another vote for me fixing dry-run behavior sooner rather than later. Will take a look at fixing all of that next weekend. Thanks for the feedback and using auto!

hipstersmoothie on 22 Oct 2020

🚀2

All 14 comments

This is by design. If the version is committed then it can lead to merge conflicts when merging into master. There is a git tag that's created though

hipstersmoothie on 22 Oct 2020

This issue is affecting me as well.

This is by design. If the version is committed then it can lead to merge conflicts when merging into master. There is a git tag that's created though

What is the recommended approach to ensure package.json versions stay in sync with CI deployments using auto shipit?

smithki on 22 Oct 2020

I'm not sure I quite understand the use case @smithki. @thuringia's use case makes sense, he needs the version to update other things, but I'm pretty hesitant to change the behavior. Can you detail what you're trying to accomplish?

hipstersmoothie on 22 Oct 2020

Sorry, I may have a misunderstanding. From the issue's wording, I surmise that next branches do not receive updated package.json versions, but main branches do (still learning auto—total beginner here). My use-case is the same as in the original issue, but to be specific:

I need to be read the package.json version at _build_ time for an NPM library so that the current package.json version can be injected as an environment variable. This means that I need to version the package.json files before the build runs. Simply importing package.json doesn't play nice with my current TypeScript setup, which depends on rootDirs in tsconfig.json (and package.json is not included in rootDirs, thus a compiler error, thus the need for an environment variable).

smithki on 22 Oct 2020

Could you just do what auto does? https://github.com/intuit/auto/blob/master/packages/core/src/auto.ts#L306-L310

hipstersmoothie on 22 Oct 2020

I'll see if I can workaround it, not my intention to derail the original topic of this issue.

Could you just do what auto does? https://github.com/intuit/auto/blob/master/packages/core/src/auto.ts#L306-L310

Unfortunately not, because the code is intended to be run client-side (I'll open a new issue if I don't find a workaround).

smithki on 22 Oct 2020

Ah, another vote for me fixing dry-run behavior sooner rather than later. Will take a look at fixing all of that next weekend. Thanks for the feedback and using auto!

hipstersmoothie on 22 Oct 2020

🚀2

@hipstersmoothie Thanks for the quick response :) You always surprise me

I found pretty solid workaround for now, auto shipit --dry-run --plugins git-tag. That actually makes a lot of sense anyways to check for the next version this way for prereleases.
Thanks for taking a shot at dry-run improvements so soon. If there's a canary build you want to try out, let me know. I'll be happy to help.

In any case, thank you so much for auto! It made my life so much easier

thuringia on 22 Oct 2020

❤1

@thuringia @smithki Could you test and see if v10 solves your issues?

hipstersmoothie on 27 Oct 2020

👍1

@hipstersmoothie This works fine in v10 👍
It is noticeably slower though, or rather it takes as long as running shipit without --dry-run.

Thanks for getting this out so quick!

Not sure if that's a bug or not:
When I upgraded the packages using yarn add -D auto@next, the changes to package.json and yarn.lock were gone after running auto shipit --dry-run. v10 was still in my node_modules so it looks like the working directory was reset.

thuringia on 28 Oct 2020

It is noticeably slower though, or rather it takes as long as running shipit without --dry-run.

I'll see if I can improve that. but since we're calling to the plugin now it doing a lot more work to print the real next versions.

the changes to package.json and yarn.lock were gone after running auto shipit --dry-run

Ah this is a bug. for the dry run I skipped the clean check but didn't skip the git reset

hipstersmoothie on 28 Oct 2020

@thuringia What type of project are you releasing?

hipstersmoothie on 28 Oct 2020

@hipstersmoothie I'm completely fine with the dry runs being slower now. It's not that big of a difference. I mostly meant it as a remark that you feel a change, maybe I should have added an emoji there 😄
Any performance boost is always welcome though.

In this case it's a mixed project consisting mostly of a Java application with some lambdas around it. To create a release I have to:

Run gradle to build the jar with the version number
package that jar in a docker image, tag it and publish it
deploy lambdas using serverless framework which uses the version number for tagging and to configure the containers

Not really a default use case for auto 😂
Usually, I use it for Node or React projects with more streamlined setups, but I never needed to get a version number before actually publishing the release like I need for this particular project

thuringia on 28 Oct 2020

:rocket: Issue was released in v10.0.0 :rocket: