DENO_AUTH_TOKENS does not authenticate against npm.pkg.github.com

[amitlevy21]

Hi,
I'm doing a POC to see if our company can start replacing node with deno.
I have a private npm package in npm.pkg.github.com that I'm trying to import.

I'm trying to run a single-line file to install the package locally:

import { Config } from "npm:@<company-name>/<package-name>/src/index.ts"

running the following command:

DENO_AUTH_TOKENS=<token>@npm.pkg.github.com NPM_CONFIG_REGISTRY=https://npm.pkg.github.com deno run -L debug file.ts

results in this error:

DEBUG RS - deno::args::config_file:756 - Config file found at '/Users/amitL/Dev/deno-poc/deno.json'
DEBUG RS - deno::args::package_json:151 - No package.json file found
DEBUG RS - deno::cache::cache_db:129 - Opening cache /Users/amitL/Library/Caches/deno/dep_analysis_cache_v1...
DEBUG RS - deno::cache::cache_db:129 - Opening cache /Users/amitL/Library/Caches/deno/node_analysis_cache_v1...
DEBUG RS - deno::auth_tokens:69 - Parsed 1 auth token(s).
DEBUG RS - deno::js:10 - Deno isolate init with snapshots.
DEBUG JS - args []
DEBUG RS - deno::worker:138 - main_module file:///Users/amitL/Dev/deno-poc/file.ts
DEBUG RS - import_map:1102 - Specifier "file:///Users/amitL/Dev/deno-poc/file.ts" was not mapped in import map.
DEBUG RS - import_map:1102 - Specifier "file:///Users/amitL/Dev/deno-poc/file.ts" was not mapped in import map.
DEBUG RS - deno::module_loader:111 - Preparing module load.
DEBUG RS - deno::module_loader:125 - Creating module graph.
DEBUG RS - deno::file_fetcher:476 - FileFetcher::fetch() - specifier: file:///Users/amitL/Dev/deno-poc/file.ts
DEBUG RS - deno_runtime::permissions:60 - ⚠️️  Granted read access to "/Users/amitL/Dev/deno-poc/file.ts"
DEBUG RS - import_map:1102 - Specifier "npm:@<company-name>/<package-name>/src/index.ts" was not mapped in import map.
DEBUG RS - reqwest::connect:429 - starting new connection: https://npm.pkg.github.com/
DEBUG RS - deno::npm::resolution:311 - Snapshot already up to date. Skipping pending resolution.
error: Error getting response at https://npm.pkg.github.com/@<company-name>/<package-name> for package "@<company-name>/<package-name>": Bad response: 401

{"error":"authentication token not provided"}

If I send a request with a client (like curl), it works, I get all the data about the package:

curl -H "Authorization: Bearer <token>" "https://npm.pkg.github.com/@<company-name>/<package-name>"

Thanks for your time!

[sigmaSd]

currently there doesn't seem to be any authorization tokens sent to npm registery?

the request here is sent immediately without setting additional authorization header

deno/cli/npm/registry.rs

Line 353 in d6e086d

.download_with_progress(package_url, &guard)

[amitlevy21]

Maybe that's why it's not working for me.

It's possible to install public npm packages with npm: specifier.
It's possible to install Deno private modules with DENO_AUTH_TOKENS .

But it seems its not possible to install private npm packages?

My use case is that we have private npm packages which we need for backwards compatibility, I want to use them in Deno without the need to maintain a deno fork version of those packages.
I tried converting the packages with denoify but this is complex since we have a monorepo for our npm packages I haven't found a way to use denoify with nx.

The most seamless and easy way would be just to provide a way to install npm private packages, perhaps there is another way, I just didn't find any in the docs

[scarf005]

this is a blocker using deno in my company too. @bartlomieju are there plans to address this issue in the near future? if not, i'm interested in opening a PR, but could you provide pointers?

currently there doesn't seem to be any authorization tokens sent to npm registery?

the request here is sent immediately without setting additional authorization header

deno/cli/npm/registry.rs

Line 353 in d6e086d

.download_with_progress(package_url, &guard)

my guess is also passing authorization token on download_with_progress but i'm not sure how or where to handle.

[ChristophLu]

Is there any progress here?
It is really important to support private NPM registries to use Deno in our company.

I think, the "tools" are already there: We have DENO_AUTH_TOKENS and NPM_CONFIG_REGISTRY. It should not be a big deal to add the auth headers to these requests.

I think #9508 relates to this. However, it still doesn't respect the .npmrc environment variables like $NODE_AUTH_TOKEN. (Or at least it refuses to read whatever I set inside _auth or _authToken= whether it was a variable or the plain text token)

The only reliable way I found to work around this fuckery was to enable the nodeModulesDir option at deno.json and install my desired dependencies using npm. Wouldn't get my hopes too high on this getting fixed soon, tho.

If you are using GitHub actions, you can mix setup-node and setup-deno:

      - id: setupnode
        name: Setup Node
        uses: actions/setup-node@v4
        with:
          node-version: 20
          registry-url: 'https://npm.pkg.github.com/'
      - id: nodeauth
        name: Authenticate to private npm registry
        run: |
          echo "//npm.pkg.github.com/:_authToken=${{ secrets.NPM_TOKEN }}" > ~/.npmrc
          npm install
      - name: Setup Deno
        uses: denoland/setup-deno@v1
        with:
          deno-version: v1.x
      # Lint, compile, whatever.

Using "vendor": true proved to be an ally when dealing with container images produced in the same way.

This however has two downsides:

1. You'll have to add your .npmrc to .gitignore which most certainly not everyone can afford to do so.
2. Haven't tried it in monorepos or anything outside this use case as my use case is not for a company. If it doesn't fit your needs, Godspeed.

Why not a simpler way?

You can get away with a simple implementation like:

1. Create a .npmrc (also ignored in your .env) file with these contents:

@yourgithub-org:registry=https://npm.pkg.github.com/
//npm.pkg.github.com/:_authToken=yourAuthToken

However, doing this makes deno compile binaries fail silently:

$ deno compile --output=build/denobin ./main.ts && ./build/denobin

error: [ERR_MODULE_NOT_FOUND] Cannot find module 'file:///tmp/deno-compile-denobin/node_modules/localhost/@my-org/examplelib/0.1.0/index.js' imported from 'file:///tmp/deno-compile-denobin/denobin/lib/core/files/addFunctions.ts'

If you try exploring, tmp/ no file exists. This leaves you with:

• No Deno compile, but a simple setup.
• Deno compiled binary but with a shitload of steps.

Update: I am an absolute idiot. Just turn on the nodeModulesDir and you should be able to fetch your deps & compile your binaries.

---

29/08/2024 update: You should be able to get everything up and running if you keep the node_modules folder and the gitignored .npmrc file.

However, if you have your CI/CD in GitHub actions, you might encounter a error: failed reading lockfile '/home/runner/work/youruser/denonpm/deno.lock' as of now I haven't found a way to correct such issue, you may ship without a lockfile tho, just make sure to deno cache first.

For Dockerfiles you may use this:

# First define your NODE_AUTH_TOKEN env var
export NODE_AUTH_TOKEN=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

RUN echo "@your-company:registry=https://npm.pkg.github.com/" > .npmrc && \ 
    echo "//npm.pkg.github.com/:_authToken=${NODE_AUTH_TOKEN}" >> .npmrc && \
    deno cache index.ts && deno task compile && \ # Assuming you have a "compile" task in your deno.json
    rm .npmrc

I really don't blame deno for this, npm ways tend to be unsuprisingly annoying sometimes.

[gmzacharydovel]

For anyone that stumbles across this, the easy workaround is to just use a package.json/npm for managing your dependencies. Install the depenencies with npm install and use deno for everything else.

You can install jsr dependencies into npm with the jsr cli which will handle most packages that people use. Esm modules do not work with this method, but those modules almost always have a npm/jsr version.

I'm sure at some point that will be fixed. But I also feel like the CloudSmith thing might also be a reason it isn't being looked at immediately. And also, as a whole, the JSR/deno ecosystem doesn't really seem to be prioritizing private repositories so I wouldn't hold my hopes up.