Authenticating GitHub private repo dependency in package.json?

Help
1

According to the official npm spec, it is permissible to add a dependency to a Node.js project by referencing a GitHub repository slug, eg:

// package.json
{
   "name": "my-package",
   "dependencies": {
      "react": "18.0.0",
      "my-pkg": "homer-simpson/electric-hammer"
   }
}

This means that I can host an npm-compatible package on GitHub at the following hypothetical repo URL…

https://github.com/homer-simpson/electric-hammer

…and it will download/install when I run npm install on the parent package that depends on it.

Here’s the results of doing that in a Vercel build:

  • :white_check_mark: Install succeeds if electric-hammer is a public repository
  • :red_circle: Install fails if electric-hammer is a private repository, with the following error:
ERROR  Command failed with exit code 128: /usr/bin/git clone git@github.com:homer-simpson/electric-hammer.git /vercel/.local/share/pnpm/store/v3/tmp/_tmp_133_92ab02168bb2f875f2f80135be5e60b1
Cloning into '/vercel/.local/share/pnpm/store/v3/tmp/_tmp_133_92ab02168bb2f875f2f80135be5e60b1'...
Host key verification failed.
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.

How can I authorise the current Vercel build script session to have credentials/access to the dependency’s repo?

Further Notes

Required Access on the dependency repo

Since my project on Vercel is owned by the same owner/org and has the same access rights as the dependency package, I would expect that the clone/download/install would succeed.

Prior Art

There was a similar topic raised in the old support forum which was not answered correctly, but marked as closed:

The answer given was erroneously focused on GitHub Package Registry authorisations rather than direct access to a registry for package. I am not using the GitHub Package Registry to host the dependency, I am using the GitHub repository itself raw-ly as the package’s source.

2

Hey,

You can start from here: How do I use private dependencies with Vercel?

3

Hi Swarnava,

I see that it’s possible to authenticate using the GitHub Personal Access token embedded in the URL of the dependency, however the official GitHub docs say:

“Treat your access tokens like passwords”

One of the big security no-nos is to commit sensitive tokens to git history, so it seems inappropriate to put the token in the package.json as plaintext. This leads me to see two options for which I’d like your input:

  • Option 1:
    • Somehow inject the sensitive token into the dependency’s URL via Vercel Environment Variables, or
  • Option 2:
    • Somehow get the Vercel build agent to use the same credentials for cloning accessing the private dependency as it does to clone the main project’s repo

Option 1

As per the linked earlier discussion, using an Environment Variable to dynamically inject into the dependency’s URL definition would look something like this:

{
  "dependencies": {
    "my-package": "https://{{ process.env.GITHUB_TOKEN }}@github.com/homer-simpson/electric-hammer"
  }

Is there a way to make that happen without resorting to a custom buildCommand that manually modifies the file after cloning?

Option 2

If the dependency is hosted in a private repo that has identical user access requirements to the Project repo, Vercel should/could be able to continue using the existing credentials in the shell session to authenticate access to the dependency’s repo.

How could I make this happen? I see that there’s a .git directory at the beginning of the build step, but I cannot determine what authentication credentials are present on disk or in memory at the time of build. Is it an SSH key? A one-time token? A machine-to-machine oauth grant?

Please help me understand which options I have here, as I’m following the official npm package.json specifications and would expect the platform to be compatible.

Thank you for your help.

4

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.