-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
Support node_modules
that live in source control
#13926
Comments
Duplicate of #13674 |
Shall I add the detail about wiping |
I think this one sounds a bit specialist - especially the We already support "vendored" packages in other manages such as |
Hi there, Help us by making a minimal reproduction repository. Before we can start work on your issue we first need to know exactly what's causing the current behavior. A minimal reproduction helps us with this. To get started, please read our guide on creating a minimal reproduction to understand what is needed. We may close the issue if you (or someone else) have not provided a minimal reproduction within two weeks. If you need more time, or are stuck, please ask for help or more time in a comment. Good luck, The Renovate team |
Repo to reproduce the issue: https://github.com/dominykas/test-renovate-13926 Build log: https://app.renovatebot.com/dashboard#github/dominykas/test-renovate-13926/568141763 This does not demonstrate the missing integrity fields (I'll revisit that later), but it does demo the failure to upgrade deps (lockfile has [email protected], but there is a 4.3.3 already available - this is because |
And the integrity part reproduced itself: https://github.com/dominykas/test-renovate-13926/pull/5/files |
What would you like Renovate to be able to do?
Having
node_modules
checked into source control is not a very common pattern, however there is at least one use case where it simplifies life a lot: creating Github Actions. GH expects all the things needed for runtime to be in the repository, so as a developer you're left with either checking in thenode_modules
or using a bundler.The feature request is two-fold:
node_modules
need to be wiped before renovation:npm
does not have the information about installed package meta data in the cache and so when it tries to recreate the shrinkwrap it does not have the checksums2. See an example resulting lock file maintenance PR: chore(deps): lock file maintenance pkgjs/action#31.node_modules
are present,npm
will not install the latest versions of the packages if the existing ones match the version range (unlessnpm update
is run), so this effectively disables the core purpose of renovate.node_modules
back into source control after the upgrade.If you have any ideas on how this should be implemented, please tell us here.
There's probably several considerations for this feature:
node_modules
)?node_modules
at the start and adding them back at the end?node_modules
maintenance" (which should probably run on a similar schedule as lock file maintenance?)Alternatively, this could maybe become a little bit more abstract, not tied to
node_modules
, and just have separate config options for "wipe these files/folders at the start" and "check these folders/files into source control when done".Is this a feature you are interested in implementing yourself?
Yes
Footnotes
lock files are not strictly necessary when checking
node_modules
in, but it is one way to ensure that the whole dependency tree receives updates via renovate. ↩one could argue that this is an issue with npm, however we have to keep in mind, that if npm did not fetch and unpack the files, then it can't really know or calculate the checksum of the unpacked files, therefore leaving it out of the lockfiles is quite possibly the correct behavior. ↩
The text was updated successfully, but these errors were encountered: