microsoft/typescript-go · error · Error

package-lock.json has ${npmPackageName}@${lockEntry.version}

Error message

package-lock.json has ${npmPackageName}@${lockEntry.version}, but ${publishedTypeScriptAliasPackageName} depends on ${version}.

What it means

getPublishedPlatformPackageLibDir requires package-lock.json's entry for the platform package to have exactly the same version string the alias's optionalDependencies declares. The lockfile is the source of the resolved tarball URL, so a lock/manifest disagreement would fetch a different build than the alias ships; the task aborts instead of mixing versions.

Source

Thrown at Herebyfile.mjs:2277

        return lib;
    }

    await fs.promises.mkdir(dest, { recursive: true });

    const tarballDestination = path.join(builtPublishedPlatformPackages, "tarballs");
    await fs.promises.mkdir(tarballDestination, { recursive: true });

    const version = getPublishedTypeScriptPackageJson().optionalDependencies[npmPackageName];
    if (!version || typeof version !== "string") {
        throw new Error(`${publishedTypeScriptAliasPackageName} does not depend on ${npmPackageName}.`);
    }

    const lockEntry = getPackageLock().packages[`node_modules/${npmPackageName}`];
    if (!lockEntry) {
        throw new Error(`package-lock.json does not contain ${npmPackageName}; run npm install.`);
    }
    if (lockEntry.version !== version) {
        throw new Error(`package-lock.json has ${npmPackageName}@${lockEntry.version}, but ${publishedTypeScriptAliasPackageName} depends on ${version}.`);
    }
    if (!lockEntry.resolved || typeof lockEntry.resolved !== "string") {
        throw new Error(`package-lock.json entry for ${npmPackageName}@${version} does not contain a tarball URL.`);
    }

    console.log(`Fetching ${npmPackageName}@${version} with npm.`);
    const { stdout } = await $pipe({ cwd: tarballDestination, env: releasePackageEnv })`npm pack --json ${npmPackageName}@${version}`;
    const [packed] = JSON.parse(stdout);
    if (!packed.filename || typeof packed.filename !== "string") {
        throw new Error(`npm pack ${npmPackageName}@${version} did not return a filename.`);
    }
    await tar.x({ file: path.join(tarballDestination, packed.filename), cwd: dest, strip: 1 });

    if (!fs.existsSync(lib)) {
        throw new Error(`Published platform package ${npmPackageName}@${version} did not contain a lib directory.`);
    }

    return lib;

View on GitHub (pinned to 1bcfa18d79)

Solutions

  1. Run `npm install` at the repo root to resync package-lock.json with the alias's optionalDependencies, then retry
  2. Confirm both sides match: compare the alias optionalDependencies value with `require('./package-lock.json').packages['node_modules/<name>'].version`
  3. If the lock is intentionally pinned, align the alias install to the pinned version instead
Defensive patterns

Strategy: validation

Validate before calling

const lockEntry = require("./package-lock.json").packages[`node_modules/${npmPackageName}`];
const wanted = require("@typescript/bundled-typescript/package.json").optionalDependencies[npmPackageName];
if (lockEntry && lockEntry.version !== wanted) {
  throw new Error(`Lock ${lockEntry.version} != alias ${wanted} — run npm install`);
}

Prevention

When it happens

Trigger: The alias was updated to a new version (e.g. dev.25.0) but package-lock.json still pins the platform package at the old one (e.g. dev.24.9) — a stale lockfile after a version bump or branch switch.

Common situations: Version bumped in CI without regenerating the lock; switching release branches with different dev versions; partial `npm install` that updated node_modules but not the lock.

Related errors


AI-assisted analysis of microsoft/typescript-go@1bcfa18d79 (2026-08-16). Data as JSON: /api/errors/31286e50437d2ae5. Report an issue: GitHub.