We've recently switched from greenkeeper to dependabot for our dependencies checks and we noticed that dependabot is opening PRs changing only package-lock.json leaving package.json as it was.
On the other hand, greenkeeper, was committing changes to both files.
What is going on? Is it normal or we missed something in the settings?
This is a very late reply. We had this working in production for a long time now, but I see there's still interest prompting me that maybe people need some help. So, here it is:
When using GitHub dependabot (not dependabot-preview, although the conf file might be the same, actually):
create a dependabot.yml file in your repo's .github directory.
specify a versioning-strategy of increase.
It will look something like this (e.g. npm):
version: 2
updates:
- package-ecosystem: "npm"
directory: "/"
schedule:
interval: "daily"
# Always increase the version requirement
# to match the new version.
versioning-strategy: increase
That's it. Now, package.json and package-lock.json are both written to with a version increase.
Something similar happened to me, it can be for two things:
In the dependendabot configurations you only have to accept updates for package-lock.json
(This was the one that worked for me) in the package.json in the key Name you may have written with incorrect symbols in my case I had web-app the symbol - caused me not to update it and now I have it as webapp.
The goal of the file package-lock.json is to keep track of the exact version of every package that is installed so that a product is 100% reproducible in the same way even if packages are updated by their maintainers.
reference link is here
So package.json and package-lock.json have different purposes.
There is no error on dependabot trying to push just a modified package-lock.json.
Related
What is the .cache folder in parcel-bundler? Is it necessary to push the .cache folder to Github ?
The .cache folder (or .parcel-cache in parcel v2) stores information about your project when parcel builds it, so that when it rebuilds, it doesn't have to re-parse and re-analyze everything from scratch. It's a key reason why parcel can be so fast in development mode. I think committing it to git would be a bad idea - it would add a large number of (unnecessary) changes to your commit history, and it could easily get out-of-sync with the code that generated it.
From this article:
Be sure to add .cache and dist to your .gitignore file to prevent
committing these folders to Git. The .cache folder is used by Parcel
as a temporary cache directory when building your app for development
and production.
A slight update on this answer, although it is practically the same response, would be that the command you now need to enter for parcel#^2.0.0-beta.1 is:
.parcel-cache
Add this to your .gitignore file and all the Blobs will be removed from your Untracked listed of files when you hit git status again.
Thank you for helping me resolve this issue!
no it is not necessary to add parcel-cache in git. one should add parcel-cache in git-ignore because parcel-cache is the space taken by parcel during production building its a binary files .This can be made again after deleting cache with a command npm run build
I have a directory /experiments in my repo which contains - surprise! - experiments. Those usually come with their own package.json which includes dependencies that were up to date at the time I made the experiment but might be outdated by now. I have no intent to keep them up to date as the experiments are just proofs of concepts - concepts I might want to use later in the project but I would then implement anew in the main project.
Unfortunately Dependapot sends me a lot of PRs that are about those dependencies in /experiments. Many of them require manual efforts on my end. So I would like to tell Dependabot to not send any notifications or create PRs for everything that is in the /experiments directory (but keep creating PRs for dependencies in the main project).
I didn't really find much docs about how to configure Dependabot on GitHub, but I came up with this:
/.github/dependabot.yml:
version: 2
updates:
# Ignore experiments:
- package-ecosystem: "npm"
directory: "/experiments"
schedule:
interval: "daily"
ignore:
- dependency-name: "*"
It doesn't seem to work though. Today I received another PR from Dependabot that bumped one of the dependencies in /experiments. It was automatically merged, so no effort on my end, but still a bit annoying.
How can I do this right?
This doesn't seem possible as of February 2022: https://github.com/dependabot/dependabot-core/issues/4364
I happened to get into a bit of a mess yesterday with our NuGet repository, and I've resolved it - but wanted to confirm my suspicions as to why it happened.
I did the following:
Amended some files
Packed the nuspec which includes these files
Pushed to our NuGet repository and confirmed
Confirmed that the NuGet repo had the latest version by downloading them on a dev environment
The changes I'd made were not included in the update in this dev environment (realised I hadn't updated the correct files). So I packed and pushed again without incrementing the version
Downloaded the nupkg on a different dev environment, still the changes were not there.
Took the exact same NuGet package and placed it in a local dir, and noticed when I updated from there it did include the changes.
Question
You'll notice as part of step 4 the old (incorrect) NuGet package was downloaded onto dev environment 1. Would NuGet have known this and, due to a lack of sound versioning, cached or kept hold of this copy somehow (despite my new push) and only allowed other dev environments this version and not the newest?
NOTE: I cleared the local cache on both dev environments prior to any updates made. My question was whether this was a server-side thing or not.
In addition to the copy of the package that is added to the packages folder in your solution NuGet will also cache packages already used in the following directory: C:\Users\YOUR_USER\.nuget\packages. Therefore if you do not change the version after making change you will have to remove the cached version from the directory I listed above for it to get the new changes since you did not change the package version.
I have the similar same problem. It's seem like a old issue.
So I will clear the http cache after I update the package version.
nuget locals http-cache -clear
It will work when you update your project package version.
I'm editing one of my open-source projects on GitHub and I want to replace link (pointing to a demo) in README.md.
Do I have to update library version every time I introduce some minor changes to the README file or documentation (without any actual code changes)?
What is the community accepted practice?
If it's important, I'm using Bower to distribute my package and SemVer as a versioning system.
The README file is part of your codebase. It should describe the current (= in current commit) state of the code. A developer might read it outside GitHub's environment, e.g. from the node_modules directory on their hard drive, expecting it is up to date.
Therefore I would recommend to release a new version when the README changes.
It will usually result in just a patch number increase. But remember that when marking something as deprecated one must release a new minor version (paragraph 7 in SemVer v2.0.0).
If you plan to do really a lot of changes there are two ways to avoid releasing too often:
Make changes in a branch. Merge to master here and there, release a new patch version.
Move the documentation (or a part of it) somewhere else. GitHub Wiki or a simple webpage, e.g. using GitHub Pages, could come in handy.
You could include, as library version, the content of of git describe --all --long, as described in How can I get the Git build number and embed it in a file? (using git describe).
That way, you get the latest tag, plus the number of (small) commits you did since that tag.
That means:
you don't have to put a new tag if you don't want to
but you still keep an exact reference the the version of your repo which was used for delivering your app.
I am working inside a private repository, and collaborate with my friend, who are not very friendly with SCM and stuff. All he need is to monitor the latest release from my development, which is 1 single executable file.
I was wondering instead of cloning the whole repo each time he want to get the latest changes (sometimes my changeset can consists of several large binary files that only being used upon development, not testing). Can I bind the executable file into the Download section in BitBucket?. So that everytime I build my project, the executable file will appear in the Download section and he can download it right away.
For now all I can see from Bitbucket's download section is just the manual upload and Tag/Snapshot download, which I presume will pack a certain changesets into a compressed file. Is there any chance I can do this?.
Thanks.
If your executable file is checked into the repository, you can link to it at a specific revision:
https://staging.bitbucket.org/<username>/<repo>/raw/<revision>/file.exe
For example, this link will always give you the latest stable hg(1) man page from the Mercurial repository:
https://bitbucket.org/mirror/mercurial/raw/stable/doc/hg.1.txt
This would give you latest README on the default branch from the Django repository:
https://bitbucket.org/django/django/raw/default/README
If your executable isn't checked into the repository (some prefer not to check in build artifacts), you'll need to manually upload them in the downloads section of your repository. There isn't a REST API for creating project downloads at the moment.
Would giving your friend an archive of the tip work? Try this URL:
https://bitbucket.org/<username>/<project>/get/tip.tar.gz
#Idan's suggestion might already work for you, but if the archive is too big, you could set up an extra repository for binaries which automatically gets updated, committed and pushed by your build process. Then your fellow developer could download a comparatively small tip archive as suggested by Idan.
In addition to Idan's answer:
To fetch the latest version from the 'default' branch:
https://bitbucket.org/<username>/<project>/get/default.tar.gz
You can replace 'default' by any other branch name, tag name or changeset (if you know it).