[BUG] GitLab tarball URL format is deprecated - causes TAR_BAD_ARCHIVE on private repos

[leocape]

Is there an existing issue for this?

• I have searched the existing issues

This issue exists in the latest npm version

• I am using the latest npm

Current Behavior

npm install with a private repo fails causes TAR_BAD_ARCHIVE: Unrecognized archive format errors when installing any git+https://gitlab.com/ dependency via npm, because npm receives an HTML sign-in page instead of a tarball.

Logs:

8304 http fetch GET 200 https://gitlab.com/users/sign_in 2090ms (cache updated) 8397 verbose stack Error: TAR_BAD_ARCHIVE: Unrecognized archive format 8397 verbose stack at Da (/Users/leo/.nvm/versions/node/v24.11.1/lib/node_modules/npm/node_modules/tar/dist/commonjs/index.min.js:3:2926) 8397 verbose stack at Hi.warn (/Users/leo/.nvm/versions/node/v24.11.1/lib/node_modules/npm/node_modules/tar/dist/commonjs/index.min.js:3:5007) 8397 verbose stack at Hi.warn (/Users/leo/.nvm/versions/node/v24.11.1/lib/node_modules/npm/node_modules/tar/dist/commonjs/index.min.js:3:49362) 8397 verbose stack at Hi.<anonymous> (/Users/leo/.nvm/versions/node/v24.11.1/lib/node_modules/npm/node_modules/tar/dist/commonjs/index.min.js:3:4268) 8397 verbose stack at Hi.emit (node:events:520:35) 8397 verbose stack at [emit] (/Users/leo/.nvm/versions/node/v24.11.1/lib/node_modules/npm/node_modules/tar/dist/commonjs/index.min.js:3:7097) 8397 verbose stack at [maybeEnd] (/Users/leo/.nvm/versions/node/v24.11.1/lib/node_modules/npm/node_modules/tar/dist/commonjs/index.min.js:3:9356) 8397 verbose stack at [consumeChunk] (/Users/leo/.nvm/versions/node/v24.11.1/lib/node_modules/npm/node_modules/tar/dist/commonjs/index.min.js:3:9676) 8397 verbose stack at Hi.write (/Users/leo/.nvm/versions/node/v24.11.1/lib/node_modules/npm/node_modules/tar/dist/commonjs/index.min.js:3:8845) 8397 verbose stack at Hi.end (/Users/leo/.nvm/versions/node/v24.11.1/lib/node_modules/npm/node_modules/tar/dist/commonjs/index.min.js:3:10337) 8398 error code TAR_BAD_ARCHIVE 8399 error TAR_BAD_ARCHIVE: Unrecognized archive format

Expected Behavior

The tarball is downloaded, not redirected to the signin html which causes the signin html to be downloaded as the tarball - which fails to verify / extract as its not a tarball

Steps To Reproduce

1. Have a private GitLab repo as a dependency: "my-pkg": "git+https://gitlab.com/my-group/my-repo.git#branch"
2. Run npm install
3. Get TAR_BAD_ARCHIVE: Unrecognized archive format
4. See logs show auth is redirecting to sign-in first (token is valid)

Old format - broken:
curl -s -o /dev/null -w "%{http_code}" -H "PRIVATE-TOKEN: $TOKEN"
"https://gitlab.com/group/repo/repository/archive.tar.gz?ref=main"

Returns: 302 (redirects to /users/sign_in)

New format - works
curl -s -o /dev/null -w "%{http_code}" -H "PRIVATE-TOKEN: $TOKEN"
"https://gitlab.com/group/repo/-/archive/main/repo-main.tar.gz"

Returns: 200

Environment

• npm: tried default npms for below, and latest: 11.11.1, 11.12.1
• Node.js: tried 18, 20, 22, 24
• OS Name: tried MacOS, Ubunutu 20,22
• System Model Name: Macbook pro / Ubuntu Server AWS / Gitlab runner self hosted on Ubuntu 22
• npm config:

; "user" config from /Users/leo/.npmrc

registry = "https://registry.npmjs.org/"

; node bin location = /Users/leo/.nvm/versions/node/v24.11.1/bin/node
; node version = v24.11.1
; npm local prefix = /Users/leo/redacted
; npm version = 11.12.1
; cwd = /Users/leo/redacted
; HOME = /Users/leo
; Run `npm config ls -l` to show all defaults.

[muzaffarmhm]

@leocape Is there any workaround for this issue ?

[AndreiDiaconovici]

We have the same issue today too.
One workaround was to use a different syntax on package.json

Someone from my team found the lucky change, not sure what is happening. I am starting to think is something related to GitLab managing the packages.

Example of working package:
"@package/core-types": "git+ssh://git@GitLab.com//core-types.git#v1.0.0",

GitLab.com must be camel case for the lucky reason.

Example of how I had it before:
"@package/core-types": "gitlab:/core-types#v1.0.0",

But then you might need to update the CI/CD pipelines authentication with GitLab to download the packages.

Hope it helps

@leocape can you open the same issue maybe also on GitLab?

[leocape]

Seems it's related to the Gitlab URL - gitlab appears to have changed (or finally deprecated support for) the old URL as mentioned above, the new URL works fine using curl, the old URL does the redirect..

Is this a Gitlab issue or a npm issue (should npm update to Gitlabs new format, or should Gitlab continue to support the legacy url) 🤔

[Dalepalmer]

@AndreiDiaconovici Huh that so odd that the camelcase url works.

Looks like this issue maybe the one on Gitlab's end -> https://gitlab.com/gitlab-org/gitlab/-/work_items/595699

[leocape]

Can confirm that using camelcase GitLab instead of gitlab works, bizarrely enough. Thanks @AndreiDiaconovici for the workaround

[babyhuey]

We hit this same issue and traced it down to the root cause in pacote.

Root cause: pacote's git fetcher (lib/git.js) tries to download a tarball from GitLab's archive endpoint first. For private repos, GitLab returns HTTP 302 → 200 (sign-in HTML page) instead of 401/403. pacote's fallback to git clone only triggers on HTTP errors (er.constructor.name.match(/^Http/)), not on tar extraction errors, so it throws TAR_BAD_ARCHIVE instead of falling back.

There are two fixes needed:

1. hosted-git-info needs to update the GitLab tarball URL template from the deprecated /repository/archive.tar.gz format to the current /-/archive/ format — [BUG] GitLab tarball URL format is deprecated - causes TAR_BAD_ARCHIVE on private repos hosted-git-info#325
2. pacote should fall back to git clone on tar errors as defense-in-depth — fix: fall back to git clone when tarball response is not a valid archive pacote#477

[mitar]

To me this is breaking installs even from a public GitLab repository.

CamelCase workaround works. Thanks.

[HcroakerDev]

We're also getting the issue.

What worked for us (temporary workaround):

1. Change GitLab git dependency host from gitlab.com to gitlab.com. (trailing dot), e.g.
   git+ssh://git@gitlab.com/group/repo.git#v1.2.3
   -> git+ssh://git@gitlab.com./group/repo.git#v1.2.3
2. If transitive deps also pull the same git package, add an overrides entry in package.json for that package to the same trailing-dot URL.

Example:

{
  "dependencies": {
    "my-private-lib": "git+ssh://git@gitlab.com./my-group/my-private-lib.git#v1.2.3"
  },
  "overrides": {
    "my-private-lib": "git+ssh://git@gitlab.com./my-group/my-private-lib.git#v1.2.3"
  }
}

After that, both npm install and npm ci succeeded.

Notes:

• This is a workaround, not a long-term fix.
• Better long-term approach is to avoid git URL deps where possible (publish/version via package registry).
• pnpm/yarn may also avoid this specific failure in some setups.

[owlstronaut]

Resolved in upcoming releases npm/hosted-git-info#328 and npm/pacote#480