Git hook update package json version - github

In our project we often forget to update version numbers in Package.json file. Ours is a AngularJS project. In our package JSON file we are specifying the below two version information
"version": "1.0.7",
"devVersion": "1.0.4"
Before Merging a branch to develop I want a automated script to update these above two version numbers. I am thinking Git Hooks will help me.
Where can i find the hooks, I am able to see the hooks in my local repo under .git folder. I am confused which hook to use. Searching on Google suggests I have to create hooks on server.
Where can i find them and can i update the above both keys (version and devVersion) ?
Pls suggest the location and hook to use, this will solve a lot of problem.

I am using husky and git-branch-is:
"scripts": {
...
"postmerge": "(git-branch-is master && npm version minor ||
(git-branch-is dev && npm --no-git-tag-version version patch)",
...
},
Read more about npm version
Webpack or Vue.js
If you are using webpack or Vue.js, you can display this in the UI using Auto inject version - Webpack plugin
NUXT
In nuxt.config.js:
var WebpackAutoInject = require('webpack-auto-inject-version');
module.exports = {
build: {
plugins: [
new WebpackAutoInject({
// options
// example:
components: {
InjectAsComment: false
},
}),
]
},
}
Inside your template for example in the footer:
<p> All rights reserved © 2018 [v[AIV]{version}[/AIV]]</p>

You have two kinds of hooks (both present in any .git/hooks folder): server and client hooks.
They are listed in "Customizing Git - Git Hooks"
A merge is a local operation, so if you wanted to automate any process during a merge, you would need a client hook, like a post-commit hook (meaning executed just after creating a merge commit).
If you need to update that file before a merge, you can try a pre-commit hook, and check if a merge is in progress (if not, your pre-commit hook would do nothing since you want to update the versions only before a merge).
You can see in this answer an example of a post-commit hook which generates a version.json file.
If is written in node, but you can write a hook ni any scripting language you want.

With Husky, it's extremely simple:
{
"name": "demo-project",
"version": "0.0.3",
"husky": {
"hooks": {
"pre-commit": "npm --no-git-tag-version version patch && git add ."
}
}
}
Note: I put git add . in the end because after we update package version, we need to stage it

Related

Mirroring pub.dev packages to a custom package repository

As of Dart 2.15, you can create your own package repository.
https://dart.dev/tools/pub/custom-package-repositories#publishing-to-a-custom-package-repository
We need to mirror the subset of pub.dev packages (for corporative security reasons).
But there's no information, how to do a package mirroring.
Should I fork a GitHub source and publish every allowed package versions manually? It looks exremely annoying and time-consuming. And what about transitive dependencies? Should I upload all of them too?
I also found this article: https://medium.com/dartlang/hosting-a-private-dart-package-repository-774c3c51dff9 , it describes the pub.dev mirroring scenario too, but doesn't explains how to do it.
I don't know if this is the answer you are looking for, but I believe that with some experimentation this could be scripted using the APIs described in the dart package repository specification:
https://github.com/dart-lang/pub/blob/master/doc/repository-spec-v2.md
For example, you can query all versions of a package like so:
curl https://pub.dev/api/packages/test
{
"version": "1.23.1",
"pubspec": {
"name": "test",
"version": "1.23.1",
...
"dependencies": {
"analyzer": ">=2.0.0 <6.0.0",
...
"test_core": "0.4.24"
},
"dev_dependencies": {
...
}
},
"archive_url": "https://pub.dartlang.org/packages/test/versions/1.23.1.tar.gz",
...
}
....
}
You can then use the archive_url for the version(s) you want to download the package, potentially iterating over the dependencies and downloading them as well.
You would then need to upload each package version you downloaded to your private repo. This can be done by first doing a GET on the new package submission URL:
curl https://my-private-repo.tld/api/packages/versions/new
{
"url": "https://my-private-repo.tld/api/packages/versions/newUpload",
"fields": {}
}
And then POST the form described by fields plus the archive you previously downloaded to the url provided in the response. Note that when I test this against unpub, the fields map is empty, but depending on your private repo implementation that may be different.
One could imagine a script that starts with a list of packages to mirror, downloads them, potentially also downloads their dependencies, and then uploads them all to the private server.
For transitive dependencies it probably depends on your security requirements. If you use PUB_HOSTED_URL=https://my-private-repo.tld then running flutter pub get will download any dependencies it can find from your private repo, and any other dependencies from pub.dev. If that is not acceptable, then you'll probably need to upload them all.

Using NuGet restore with lock files gives "NU1004: The packages lock file is inconsistent with the project dependencies" error

I am getting this error when I use the -LockMode switch with the nuget restore command.
NU1004: The packages lock file is inconsistent with the project
dependencies so restore can't be run in locked mode. Disable the
RestoreLockedMode MSBuild property or pass an explicit
--force-evaluate option to run restore to update the lock file.
What I am trying to achieve is to automatically upgrade my nuget references by using wildcards but use specific versions when I want to re-build my project from known sources. this blog posts describes how this can be achieved Enable repeatable package restores using a lock file.
When I use -UseLockFile & -LockMode on a simple solution with just one project it works as expected, the issue arises when I start adding another project to the solution.
Here're the steps:
I have published my package to an Azure DevOps feed and I have the following versions listed:
1.0.1-ci.1
1.0.1-ci.2
I have created a .Net 3.1 console app that references my package using wild cards, i.e. <PackageReference Include="My.Package" Version="1.0.*-ci.*" />
Running the command nuget restore -UseLockFile -ForceEvaluate creates the packages.lock.json with the right reference (I am using -ForceEvaluate in order to ensure it always resolves to the latest version available on the feed), the contents of the lock file of my console project are:
{
"version": 1,
"dependencies": {
".NETCoreApp,Version=v3.1": {
"My.Package": {
"type": "Direct",
"requested": "[1.0.*-ci.*, )",
"resolved": "1.0.0-ci.2",
"contentHash": "4HQuN7LNoZT9Z+MOL/Yig79FehhXBZmi26j3VtWR9Cgz8k5irWspSQ8aasVbNkYp7AgA2XaDQdr/cnwJnPilpQ=="
}
}
}
}
I then publish a new version of My.Package (1.0.1-ci.3) and run the command nuget restore -LockedMode, and the version resolved is still 1.0.1-ci.2, and if I then run nuget restore -ForceEvaluate it will resolve as expected to 1.0.1-ci.3, so far so good!
The issue arises when I add a class library to my solution which uses the same package reference, i.e. <PackageReference Include="My.Package" Version="1.0.*-ci.*" />, when I run restore -UseLockFile -ForceEvaluate my packages.lock.json file is updated to include the project dependency:
{
"version": 1,
"dependencies": {
".NETCoreApp,Version=v3.1": {
"My.Package": {
"type": "Direct",
"requested": "[1.0.*-ci.*, )",
"resolved": "1.0.0-ci.3",
"contentHash": "4HQuN7LNoZT9Z+MOL/Yig79FehhXBZmi26j3VtWR9Cgz8k5irWspSQ8aasVbNkYp7AgA2XaDQdr/cnwJnPilpQ=="
},
"classlibrary1": {
"type": "Project",
"dependencies": {
"My.Package": "1.0.0-ci.0"
}
}
}
}
}
While the contents of the lock file of the Class Library project are:
{
"version": 1,
"dependencies": {
".NETCoreApp,Version=v3.1": {
"My.Package": {
"type": "Direct",
"requested": "[1.0.*-ci.*, )",
"resolved": "1.0.0-ci.3",
"contentHash": "4HQuN7LNoZT9Z+MOL/Yig79FehhXBZmi26j3VtWR9Cgz8k5irWspSQ8aasVbNkYp7AgA2XaDQdr/cnwJnPilpQ=="
}
}
}
}
After this when I try running restore -LockMode I get the NU1004 error mentioned earlier.
Doing what the error message suggests and use -ForceEvaluate would clearly break what I wanted to achieve, yet I can't imagine that this relatively simple scenario is not covered by NuGet, so I would guess I am doing something wrong, does anyone have any ideas of what I could try to make this work?
It sounds like you're adding a new dependency then running nuget restore -LockedMode without first running nuget restore -ForceEvaluate.
It's not obvious what NuGet should do in that case - you're telling it you only want to use the dependencies in your lock file but you've also added new dependencies too.
It sounds like this would typically fail the restore:
If locked mode is set, restore will either get the exact packages as listed in the lock file or fail if it cannot. For example, if you updated the defined package dependencies for the project after lock file was created
https://devblogs.microsoft.com/nuget/enable-repeatable-package-restores-using-a-lock-file/#why-use-a-lock-file
You might have hit a corner case if the only transitive dependency of your new dependency is one that's already in the lock file but at a different version.
In general though, whenever you add new dependencies you're going to need to update your lock file, then after that you should be set to carry on running nuget restore -LockedMode.

Publishing Github packages for a monorepo as part of an organization

I have a Lerna monorepo on Github Enterprise which currently has two npm packages that I'm trying to publish to the Github package registry under the same repo.
For reference say they are:
github.com/mycompany/package-a
github.com/mycompany/package-b
I followed these instructions: https://help.github.com/en/github/managing-packages-with-github-packages/configuring-npm-for-use-with-github-packages#publishing-multiple-packages-to-the-same-repository
So now my 2 package.json files look like the following (trimmed for formatting purposes):
"name": "#mycompany/package-a",
"repository": {
"url": "ssh://git#github.com:mycompany/monorepo.git"
},
"publishConfig": {
"registry": "https://npm.pkg.github.com/"
},
"name": "#mycompany/package-b",
"repository": {
"url": "ssh://git#github.com:mycompany/monorepo.git"
},
"publishConfig": {
"registry": "https://npm.pkg.github.com/"
},
So you can notice they both have the same URL for the repository as recommended.
First problem: One is that my company already has repos called package-a and package-b. It seems that you can't have a naming collision with a package in a monorepo and a package outside the monorepo.¹
Second and more important problem: This doesn't seem to work for me at all. I renamed the package in their respective package.json files to avoid the naming collision to package-a-mono and package-b-mono which I don't really want to do but I'm just trying to get it to work. I get a 404 when trying to run either lerna publish or npm publish inside of the repos themselves. Like it's not actually trying to read that repository.url field in that it tells you to modify.
^ This turned out to be temporary or was never actually an issue, it was just because of the naming conflicts.
npm publish output:
npm ERR! code E404
npm ERR! 404 Not Found - PUT https://npm.pkg.github.com/#mycompany%2fpackage-a - The expected resource was not found.
lerna publish output:
lerna http fetch PUT 404 https://npm.pkg.github.com/mycompany/#mycompany%2fpackage-a 327ms
lerna ERR! E404 The expected resource was not found.
Has anyone run into this and found a solution?
¹On a somewhat worse note, for some reason the very first time I ran this it actually did publish a package into the monorepo for package-a. But from then on I get the error lerna ERR! E422 Package "package-a" is already associated with another repository. Nothing changed and I couldn't publish another version to the same repo.
Another possible cause of this error (discussed and ruled out in the original question body) is if any package's package.json's repository field does not match the git URL of the repo - for example, if you transferred the repo to a different organisation, or renamed the repo, but didn't update every package's package.json with the new URL.
The error message will report 404 on https://npm.pkg.github.com/#org/package-name even if the problem is with the repository URL.
(credit to jonas-reif's comment)
The issue here was that we had repos in the organization with the same name as the package being published and it didn't like that.
When I looped back around to solving this I renamed the packages to not have a collision with another existing repo in the organization and it worked as expected.
I ran into the same issue, I had to generate a new personal access token that had more privileges. Just read:packages and write:packages was not sufficient, you also needed repo.
I had the same problem and I had to add the following line to my NPM package's URL:
"repository": "https://github.com/ACCOUNT/REPOSITORY"
This repository was the root of my mono repository.
More on this here:
https://docs.github.com/en/packages/working-with-a-github-packages-registry/working-with-the-npm-registry#publishing-multiple-packages-to-the-same-repository

Yarn can't find private Github npm registry

I signed up for the Github private npm registry beta and followed their instruction: https://github.com/features/package-registry
Works great with npm but I'd prefer using yarn. And while npm has no issues finding the registered package, yarn can't find it at all.
yarn add #omniphx/adminite-adminite-ui-components outputs:
yarn add v1.19.0
info No lockfile found.
warning package-lock.json found. Your project contains lock files generated by tools other than Yarn. It is advised not to mix package managers in order to avoid resolution inconsistencies caused by unsynchronized lock files. To clear this warning, remove package-lock.json.
[1/4] 🔍 Resolving packages...
error Couldn't find package "#omniphx/adminite-ui-components" on the "npm" registry.
info Visit https://yarnpkg.com/en/docs/cli/add for documentation about this command.
After reading up on private repos with yarn, I thought the trick was due to yarn having a slightly different rc format. Unfortunately, that didn't work either and yarn is still unable to find the private registry.
.npmrc
registry=https://registry.npmjs.org
#omniphx:registry=https://npm.pkg.github.com/omniphx
.yarnrc
registry "https://registry.npmjs.org"
"#omniphx:registry" "https://npm.pkg.github.com/omniphx"
Also confirmed that my github token is set too with yarn config list:
yarn config v1.19.0
info yarn config
{
'version-tag-prefix': 'v',
'version-git-tag': true,
'version-commit-hooks': true,
'version-git-sign': false,
'version-git-message': 'v%s',
'init-version': '1.0.0',
'init-license': 'MIT',
'save-prefix': '^',
'bin-links': true,
'ignore-scripts': false,
'ignore-optional': false,
registry: 'https://registry.npmjs.org',
'strict-ssl': true,
'user-agent': 'yarn/1.19.0 npm/? node/v12.11.1 darwin x64',
email: 'mattjmitchener#gmail.com',
lastUpdateCheck: 1570679687836,
username: 'omniphx',
'#omniphx:registry': 'https://npm.pkg.github.com/omniphx'
}
info npm config
{
'//npm.pkg.github.com/:_authToken': 'fake12345',
registry: 'https://registry.npmjs.org',
'#omniphx:registry': 'https://npm.pkg.github.com/omniphx',
python: '/usr/bin/python'
}
Any idea?
Resolved
Changed "#myorg:registry" "https://npm.pkg.github.com/myorg"
To "#myorg:registry" "https://npm.pkg.github.com"
I've just run into a similar situation. It seemed that yarn was only looking in the main Yarn package registry for my organization's private package. I had copied the examples from GitHub's Packages documentation for constructing your .npmrc file directly to the .yarnrc file in the project that will be consuming the app, not knowing that the formats were different (I've never had to deal with .yarnrc files before).
However, after updating the .yarnrc file with the correct format that you've mentioned above (which I also found in googling around), yarn successfully found the private package and installed it correctly.
As a heads up, my yarn version: 1.17.3
Steps I Took
Start new terminal session
cd to the project
nvm use (if you have a specific node version to use)
Add the correctly-formatted .yarnrc file to the project. See below for what it looks like.
Manually add the package and version range to the package.json for my private package
Run npm login --registry=https://npm.pkg.github.com --scope=#MyOrg
See the note below on scope / org gotcha's
Run yarn
That worked for me.
.yarnrc
"#myorg:registry" "https://npm.pkg.github.com"
Note: See below for a note on the org / scope name gotcha's
Other Notes
I know that it appears that you don't have any issues with this, given your GH username / scope above, but for anyone else that comes here, the documentation on GH is a little sparse with regards to mapping your username / org name to a scope in the package name. Just remember these little gotcha's here:
The name of your package must always be scoped to your org (or username)
E.g., name: #johndturn/my-package
If your organization has capital letters in it, like MyOrg, just replace them in the name of the package in your package.json and your .yarnrc with lowercase
E.g., name: #myorg/my-package
Note: When authenticating with npm login, I still have kept the uppercase letters in the --scope= argument.
The name of your package doesn't have to be the same name of the repo.
E.g., for a repo called MyOrg/random-prefix.js-lib, you can have name: #myorg/js-lib in your package.json file for the project itself. Then, installing it in other projects will look something like #myorg/js-lib: 1.0.0.
The problem I had is slightly different.
After tried what John suggested I still can't add private registry packages with yarn (but perfectly fine with npm)
Then I realise two things:
For GitHub packages, npm is fine with either
registry=https://npm.pkg.github.com/my-org
or
#my-org:registry=https://npm.pkg.github.com
but yarn only allow the latter syntax.
Docs from Github website only show the first syntax which could cause problems for yarn users.
Another thing is that if you npm login to the private registry but use a .yarnrc file in your project, yarn can't really mix your npm credentials with it. Although it seems behave differently on different environment.
But it would seems to be a best practice to stick with either yarn login + .yarnrc, or npm login + .npmrc (you can still use yarn to manage your packages in both cases)
In Yarn v2+ the setup has changed quite a bit. ".yarnrc" is ignored and only ".yarnrc.yml" is used.
To setup a private registry with a scope and token from env, add something along these lines to the ".yarnrc.yml" file (fontawesome example):
npmScopes:
fortawesome:
npmRegistryServer: "https://npm.fontawesome.com"
npmAuthToken: ${FONTAWESOME_TOKEN}
Documentation: https://yarnpkg.com/configuration/yarnrc#npmScopes
I'm not an expert with npm/yarn so I might be misunderstanding what is happening here, but I don't think package proxying from the npm registry works with yarn yet. Could that be related? When package proxying was released for npm I remember reading comments on Twitter from people that tried it with yarn and it didn't work.
Found the Twitter thread here:
https://twitter.com/github/status/1171832034580451328
It doesn't work with Yarn. As soon as I change the registry url -> Couldn't find package.

How to use (environment) variables for a package.json dependency in npm?

In npm, I want to be able to install a package from a private GitHub repo as a dependency through the git+https way without having to hardcode the actual github_username:personal_access_token, but rather plug them into the dependency string as (environment) variables.
So instead of
package.json:
...
"dependencies": {
...
"my-private-github-repo": "git+https://<github_username>:<personal_access_token>#github.com/some/package.git",
...
}
I would like something like this:
package.json:
...
"dependencies": {
...
"my-private-github-repo": "git+https://${github_username}:${personal_access_token}#github.com/some/package.git",
...
}
Hardcoding credentials is a major no-no when applying version control to package.json which I'd like to be able to do.
What is the best way to do this?
Create .env file at the same directory level where package.json resides.
Mention PERSONAL_ACCESS_TOKEN=******************************* into .env file
Don't forget to add .env into .gitingore list which will prevent exposing key to outside world while you make git commit to your repo.
Now you can add your dependency in package.json as below,
"dependencies": {
...
"my-private-github-repo": "git+https://${ENV.PERSONAL_ACCESS_TOKEN}#github.com/USER/abcd-repo-3.4.0.git",
...
}
There are other ways using 'DOTENV' npm package, but it could not do much when we are trying to resolve "Github" package dependency. Above seems to be straight forward solution.