bun x/bun run is not using defined version of the dependency

[woehrl01]

What version of Bun is running?

v1.0.6 (969da088)

What platform is your computer?

ubuntu-22.04 (public github action runner)

What steps can reproduce the bug?

Install a dependency, e.g. tsc and run it via "bun run". Sometimes it's not executing with the right version (if there is a preinstall already)

What is the expected behavior?

Run tsc in the installed version

What do you see instead?

Running it in a different version

Additional information

bun install v1.0.6 (969da088)
[...]
 + typescript@5.2.2
[...] 
  571 packages installed [6.32s]

Executing tsc via package.json scripts:

 $ tsc --version && tsc
Version 5.1.5

Most of the time it works correctly, but sometimes it runs on a different version.

[woehrl01]

This also applies to bun x with the same setup:

[woehrl01]

Same behaviour also happens with 1.0.7

[woehrl01]

Same behaviour in 1.0.8. Quite serious in a CI/CD environment. Where suddenly other versions are used.

[Jarred-Sumner]

@woehrl01 are you using bunx or bun run? They behave differently. bun run should use the local one in node_modules/.bin. bunx should too, but if for any reason the package.json doesn’t specify the version it will not

[woehrl01]

The package.json have pinned versions and the bun install is using frozen-lockfile on restore. Eiter using bun x or just bun run does not make a difference. The behaviour happens about 1 of 20-30 ci/cd builds. @Jarred-Sumner

[woehrl01]

Just happened again with 1.0.9 @Jarred-Sumner

[woehrl01]

Just happend in 1.0.10

[dylan-conway]

having trouble reproducing this behavior. Can you post the package json you are using for this CI workflow, or is this workflow public?

[woehrl01]

This is the dependency part of our package.json which has this behaviour once in a while:

  "dependencies": {
    "@abraham/reflection": "0.12.0",
    "@aws-sdk/client-auto-scaling": "3.441.0",
    "@aws-sdk/client-dynamodb": "3.441.0",
    "@aws-sdk/client-ec2": "3.441.0",
    "@aws-sdk/client-elastic-load-balancing-v2": "3.441.0",
    "@aws-sdk/client-signer": "3.441.0",
    "@aws-sdk/client-sts": "3.441.0",
    "@aws-sdk/credential-providers": "3.444.0",
    "@aws-sdk/signature-v4": "3.374.0",
    "@aws-sdk/signature-v4-crt": "3.438.0",
    "@octokit/rest": "20.0.2",
    "ajv": "8.12.0",
    "cdk8s": "2.64.7",
    "compressing": "1.10.0",
    "constructs": "10.1.242",
    "csv-parse": "5.5.2",
    "dashify": "2.0.0",
    "dedent-js": "1.0.1",
    "ejs": "3.1.9",
    "patch-package": "8.0.0",
    "punycode": "2.3.1",
    "tlds2": "2.2.10",
    "tsyringe": "4.8.0",
    "winston": "3.11.0",
    "xxhash-wasm": "1.0.2",
    "yaml": "2.3.4"
  },
  "devDependencies": {
    "@types/dashify": "1.0.3",
    "@types/ejs": "3.1.5",
    "@typescript-eslint/eslint-plugin": "6.10.0",
    "@typescript-eslint/parser": "6.10.0",
    "bun-types": "1.0.10",
    "cdk8s-cli": "2.2.31",
    "eslint": "8.53.0",
    "eslint-plugin-deprecation": "2.0.0",
    "jsonfile": "6.1.0",
    "prettier": "3.0.3",
    "typescript": "5.2.2"
  }

[ItsJPrentice]

Confirming that I'm still seeing this behavior intermittently on 1.0.11.

[Jarred-Sumner]

We’re having trouble reproducing. Can you send a zip of the repository where it happens and we can take a look?

[ItsJPrentice]

project.zip

Note that I am unable to reproduce this locally. It only takes place when I run in an Azure DevOps Pipeline and then, intermittently.

I tested again this morning with the code included in the attached .zip. Two different runs, two different results.

[woehrl01]

@dylan-conway looks like this is fixed with the 1.0.12/1.0.13 release. 🎉

@ItsJPrentice can you confim?

[ItsJPrentice]

@woehrl01 Yes, I just got 5 successful runs with the correct version called every time. Thanks team!

[woehrl01]

@ItsJPrentice awesome, I'll close the issue.

[barrozolucas]

Apologies for bringing this up again, but I've also encountered this issue recently.

Executing bun ./index.ts using the setup provided below leads to the installation of a different package version instead of the one specified in the package.json file.

This behaviour differs from what is outlined in the documentation at https://bun.sh/docs/runtime/autoimport#version-resolution.

...scan up the tree for a package.json that includes "foo" as a dependency. If found, use the specified semver version or version range.

Could anyone shed some light on it?

---

{
  "dependencies": {
    "date-fns": "1.30.1"
  }
}

// index.ts

import { format } from 'date-fns';

console.log(format(new Date(), 'YYYY-MM-DD'));

bun ./index.ts
Use `yyyy` instead of `YYYY` (in `YYYY-MM-DD`) for formatting years to the input `Tue Feb 13 2024 18:23:09 GMT+0100 (Central European Standard Time)`; see: https://github.com/date-fns/date-fns/blob/master/docs/unicodeTokens.md
12 | }
13 |
14 | export function warnOrThrowProtectedError(token, format, input) {
15 |   const _message = message(token, format, input);
16 |   console.warn(_message);
17 |   if (throwTokens.includes(token)) throw new RangeError(_message);
                                              ^
RangeError: Use `yyyy` instead of `YYYY` (in `YYYY-MM-DD`) for formatting years to the input `Tue Feb 13 2024 18:23:09 GMT+0100 (Central European Standard Time)`; see: https://github.com/date-fns/date-fns/blob/master/docs/unicodeTokens.md
      at warnOrThrowProtectedError (/Users/lucas.barrozo/.bun/install/cache/date-fns@3.3.1/_lib/protectedTokens.mjs:17:42)
      at /Users/lol/.bun/install/cache/date-fns@3.3.1/format.mjs:416:9
      at map (:1:21)
      at format (/Users/lol/.bun/install/cache/date-fns@3.3.1/format.mjs:404:10)