Dependabot-core: package-lock.json downgrades from v2 (newly released npm@7) to v1

[AviVahl]

Package manager/ecosystem
npm (newly released 7!)

Manifest contents prior to update
Irrelevant.

Updated dependency
Any?

What you expected to see, versus what you actually saw
I expected dependabot to see "lockfileVersion": 2, in package-lock.json and use npm@7.

Images of the diff or a link to the PR, issue or logs
https://github.com/AviVahl/ts-tools/pull/92

[saschanaz]

Somehow it even does not actually bump the version: https://github.com/w3c/webidl2.js/pull/500

[Kjaer]

Same happening on my private repos, better to take care of this soon, because now I manually upgrade the deps :/

[mikecousins]

Yeah this one is annoying. I've had to disable dependabot now for Javascript.

[Ignigena]

I'm observing similar but slightly different behaviour when using NPM 7 in combination with the Workspaces feature.

In this scenario, for dependencies inside of one of the workspace folders, Dependabot ignores entirely the root package-lock.json file. It only bumps the version number or range in the package.json for the relevant subdirectory.

In my case I've even specified NPM 7 under the engines option in the root package.json but Dependabot seems to ignore this entirely as indicated by prior posts.

[stefcameron]

I can confirm the reported behavior. Very annoying. When the bot runs, it downgrades my lockfile to v1. Then when I pull the latest code and npm install, I get a package-lock.json change because NPM converts the lock file back to v2. And it's not just the internal version code that changes. The entire structure of the lock file changes because of significant changes made to the v2 format with npm@7.

The bot should detect the lock file version and use the corresponding NPM CLI.

[stefcameron]

Even more concerning is whether NPM <=6 is actually _recreating_ the lock file at v1 rather than _downgrading_ it. That would be very bad. Means every time the bot runs, my locks are voided and replaced with current, defeating the purpose of the lock file... I can see NPM 7 _converting_, but NPM 6 or less wouldn't know about this new format, so I wouldn't be surprised if it's an overwrite rather than a downgrade that doesn't alter any of the locked versions...

[longility]

I really want to use dependabot. Like some here, I have to disable dependabot for now. I’m waiting for this to be done before enabling. 😞

[sayantan300]

Hey everyone here, u can try a feature I guess, GitHub actions itself keeps npm V6, so I added a postinstall script to update npm to npm@latest (V7) and then reinstall it, so you can try that in your repos if possible...

[sayantan300]

Alternative way is to manually check for updates through this:
https://www.npmjs.com/package/npm-check-updates

[BorntraegerMarc]

https://github.com/dependabot/dependabot-core/blob/main/CHANGELOG.md#v01301-14-january-2021 states that dependabot is compatible with npm v7

However I'm using dependabot native GitHub integration and for me it does not detect npm v7 lockfiles and overwrites it...

[jurre]

https://github.com/dependabot/dependabot-core/blob/main/CHANGELOG.md#v01301-14-january-2021 states that dependabot is compatible with npm v7

That's maybe a little confusingly worded on our side, apologies. We are working on adding npm 7 support and that release allowed us to _detect_ if we should be using npm 7, but it doesn't actually run the update against npm 7 yet. We hope to land it soon though! You can follow along here: https://github.com/dependabot/dependabot-core/pull/3011

[BorntraegerMarc]

Thank you for the clarification @jurre

Is GitHub's native Dependabot always using the latest dependabot-core version?

It would be helpful to know, because once the PR is merged we would like to upgrade npm once GitHub supports npm v7.

[jurre]

Is GitHub's native Dependabot always using the latest dependabot-core version?

Yeah we track it pretty closely although there is a delay between releasing a version and rolling it out into production. It's a semi-manual process so sometimes we release a version and roll it out the next day.

We'll publish an update on the GitHub changelog when support has landed though, and I'll make sure to ping folks here as well.

[AraHaan]

@jurre is there also perhaps a way we can get an command line version of dependabot that we can deploy ourselves that increments all updates (if any) at once within github actions and bundle all updates into a single pr using the create-pull-request action that way we do not need to worry about the one built into github whenever new releases land and then make an setup-dependabot action that any workflow can basically use with the type of updates they need to run on the project (that would accept what settings are possible in the dependabot.yml file without needing to supply that file to the action)?

Basically what I am asking for is a way to basically do the things that dependabot can do normally, as an github action that would update only the checked out files in the workflow, and then we could use the create-pull-request action to commit, make a branch, and pull request with all of the changes bundled together.

I currently do this with submodules too since dependabot seems to not know how to update those yet either which is sad.

Same for the inability to set dependabot to run every hour or every x minutes if we wanted it to check that frequently instead of "daily" as sometimes people deploy updates, not daily and sometimes by the end of the day results in a big jump of version a prime example is using dev packages to .NET 6.

[jurre]

@AraHaan yeah that's totally possible and people do this, https://github.com/dependabot/dependabot-script is a good place to start for inspiration on how to run dependabot standalone, and here is a more full fledged example of running Dependabot as an action: https://github.com/CGA1123/dependabot-lein-runner