[Bug?]: yarn add unexpectedly hangs in network restricted environments

[sebdanielsson]

Self-service

• I'd be willing to implement a fix

Describe the bug

yarn add appears to make an additional HTTPS request to Algolia during dependency addition when the project looks like a TypeScript project.

In my environment, that external request is blocked by the corporate proxy fick a 407, so yarn add hangs. yarn install works as expected against the configured internal registry.

I can think of multiple ways to handle this better:

1. Add a timeout for the Algolia request (10 seconds?) and log an error when it fails to make the user aware of the issue but enabling them to install the package. The message could also mention that this issue can be bypassed with: tsEnableAutoTypes: false or YARN_TS_ENABLE_AUTO_TYPES="false"
2. Do 1 but abort the installation (current behavior but stricter)
3. Disable this functionality by default when a non-scoped 3rd party registry is configured

To reproduce

In a restricted network environment, run:

yarn add is-number

Yarn will hang indefinately.

Environment

System:
  OS: Linux 6.6 Ubuntu 24.04.4 LTS 24.04.4 LTS (Noble Numbat)
  CPU: (28) x64 13th Gen Intel(R) Core(TM) i7-13850HX
Binaries:
  Node: 24.14.0 - /tmp/xfs-60f29291/node
  Yarn: 4.10.3 - /tmp/xfs-60f29291/yarn
  npm: 11.9.0 - /home/username/.local/share/mise/installs/node/24/bin/npm
  bun: 1.3.11 - /home/username/.bun/bin/bun
npmPackages:
  jest: ^30.3.0 => 30.3.0

Additional context

Troubleshooted with GitHub Copilot Agent Mode GPT-5.4 xhigh thinking.

Here's the full report:

yarn add performs an unexpected external Algolia request in TypeScript projects and hangs behind restricted proxies, while yarn install succeeds with the configured npm registry

Summary

In Yarn 4.10.3, yarn add appears to make an additional HTTPS request to Algolia during dependency addition when the project looks like a TypeScript project. This happens even when a custom npm registry is configured and the package version is explicit.

In my environment, that external request is blocked by the corporate proxy, so yarn add hangs or times out. yarn install works as expected against the configured internal registry.

This looks less like npmRegistryServer being ignored and more like yarn add having an unexpected external network dependency during its TypeScript auto-types path.

Environment

• Yarn: 4.10.3
• Corepack: 0.34.6
• Node: 24.14.0
• OS: Linux
• Custom npm registry configured via environment variables:

export COREPACK_NPM_REGISTRY="https://proget.company.local/npm/DefaultNpm"
export npm_config_registry="https://proget.company.local/npm/DefaultNpm/"
export YARN_NPM_REGISTRY_SERVER="https://proget.company.local/npm/DefaultNpm/"

• External HTTPS traffic is subject to a corporate proxy
• Direct access to the Algolia host used by Yarn fails in this environment:

$ curl -I -L https://ofcncog2cu-dsn.algolia.net
HTTP/1.1 407 authenticationrequired
...
curl: (56) CONNECT tunnel failed, response 407

Expected behavior

yarn add and yarn install should have consistent network behavior with respect to the configured npm registry.

At minimum:

• yarn add <pkg>@<version> should not require unrelated external hosts outside the configured registry
• If the external lookup is only for optional TypeScript auto-types behavior, failure to reach it should not block or hang the main yarn add operation
• A best-effort @types lookup should degrade gracefully when offline or behind a restrictive proxy

Actual behavior

In a minimal TypeScript project, yarn add is-number@7.0.0 times out and logs an outgoing request to Algolia:

HTTP ... createConnection ofcncog2cu-dsn.algolia.net:443...
GET https://ofcncog2cu-dsn.algolia.net/1/indexes/npm-search/is-number?x-algolia-agent=Algolia%20for%20JavaScript%20(4.22.1)%3B%20Node.js%20(24.14.0)&attributesToRetrieve=%5B%22types%22%5D

This request is unrelated to the configured npm registry.

Minimal reproduction

Repro that hangs

mkdir repro-ts
cd repro-ts

cat > package.json <<'EOF'
{
  "name": "yarn-ts-repro",
  "private": true,
  "packageManager": "yarn@4.10.3"
}
EOF

cat > tsconfig.json <<'EOF'
{
  "compilerOptions": {
    "target": "ES2022"
  }
}
EOF

export COREPACK_NPM_REGISTRY="https://proget.company.local/npm/DefaultNpm"
export npm_config_registry="https://proget.company.local/npm/DefaultNpm/"
export YARN_NPM_REGISTRY_SERVER="https://proget.company.local/npm/DefaultNpm/"

NODE_DEBUG=http,https yarn add is-number@7.0.0

Observed result:

• command timed out in my environment
• debug log showed an outgoing request to ofcncog2cu-dsn.algolia.net
• the request was querying the Algolia npm-search index for the package name and attributesToRetrieve=["types"]

Control 1: same project, but yarn install

mkdir repro-ts-install
cd repro-ts-install

cat > package.json <<'EOF'
{
  "name": "yarn-ts-install",
  "private": true,
  "packageManager": "yarn@4.10.3",
  "dependencies": {
    "is-number": "7.0.0"
  }
}
EOF

cat > tsconfig.json <<'EOF'
{
  "compilerOptions": {
    "target": "ES2022"
  }
}
EOF

export COREPACK_NPM_REGISTRY="https://proget.company.local/npm/DefaultNpm"
export npm_config_registry="https://proget.company.local/npm/DefaultNpm/"
export YARN_NPM_REGISTRY_SERVER="https://proget.company.local/npm/DefaultNpm/"

NODE_DEBUG=http,https yarn install

Observed result:

• succeeds immediately
• no Algolia request appears in the debug log
• dependency is resolved and installed normally

Control 2: same TypeScript project, but disable auto-types

mkdir repro-ts-no-autotypes
cd repro-ts-no-autotypes

cat > package.json <<'EOF'
{
  "name": "yarn-ts-repro",
  "private": true,
  "packageManager": "yarn@4.10.3"
}
EOF

cat > tsconfig.json <<'EOF'
{
  "compilerOptions": {
    "target": "ES2022"
  }
}
EOF

cat > .yarnrc.yml <<'EOF'
tsEnableAutoTypes: false
EOF

export COREPACK_NPM_REGISTRY="https://proget.company.local/npm/DefaultNpm"
export npm_config_registry="https://proget.company.local/npm/DefaultNpm/"
export YARN_NPM_REGISTRY_SERVER="https://proget.company.local/npm/DefaultNpm/"

NODE_DEBUG=http,https yarn add is-number@7.0.0

Observed result:

• succeeds immediately
• no Algolia request appears
• package is added and installed normally

Control 3: no TypeScript project

mkdir repro-no-ts
cd repro-no-ts

cat > package.json <<'EOF'
{
  "name": "yarn-add-repro",
  "private": true,
  "packageManager": "yarn@4.10.3"
}
EOF

export COREPACK_NPM_REGISTRY="https://proget.company.local/npm/DefaultNpm"
export npm_config_registry="https://proget.company.local/npm/DefaultNpm/"
export YARN_NPM_REGISTRY_SERVER="https://proget.company.local/npm/DefaultNpm/"

NODE_DEBUG=http,https yarn add is-number@7.0.0

Observed result:

• succeeds immediately

Likely cause

This appears to come from Yarn's TypeScript plugin hook that runs on yarn add.

In the bundled Yarn 4.10.3 code, there is a tsEnableAutoTypes setting and an afterWorkspaceDependencyAddition hook. When tsEnableAutoTypes is null, the hook auto-enables if tsconfig.json exists. It then queries the Algolia npm-search index with attributesToRetrieve: ["types"] to decide whether it should auto-add a matching @types/* package.

That means:

• yarn add in a TypeScript project can depend on external Algolia access
• this happens even when the dependency version is already explicit
• this behavior is separate from the configured npm registry
• if Algolia is blocked or unreachable, the main yarn add flow can hang

If this lookup is intended as an optimization for auto-installing @types, it probably should not be a hard network dependency for yarn add.

Why this is surprising

From a user perspective, I configured Yarn to use an internal npm registry and expected yarn add and yarn install to behave the same way.

Instead:

• yarn install respects the internal registry and succeeds
• yarn add introduces an unrelated external dependency
• the command appears to hang rather than failing fast or degrading gracefully

That makes this look like a registry issue, but the actual blocker is the unexpected Algolia request.

Workaround

Setting the following in .yarnrc.yml avoids the issue:

tsEnableAutoTypes: false

After doing that, yarn add is-number@7.0.0 succeeds immediately in the same environment.

Suggested fix

Any of these would address the problem:

• do not contact Algolia during yarn add unless the user explicitly opted into that behavior
• skip the external lookup when a custom npm registry is configured
• skip the external lookup when the dependency version is already explicit
• treat the lookup as best-effort and never let it block the main add flow
• document clearly that yarn add may contact Algolia in TypeScript projects unless tsEnableAutoTypes: false is set