`bun install .` not working

[mathiasrw]

What version of Bun is running?

1.0.1+31aec4ebe325982fc0ef27498984b0ad9969162b

What platform is your computer?

Darwin 21.6.0 arm64 arm

What steps can reproduce the bug?

Have a local repo that is a regular npm module with a "bin" path in package.json. Example:

git clone https://github.com/piuccio/cowsay.git
cd cowsay

What is the expected behavior?

I can install the npm module globally from my local copy by referencing the folder. If im in the root dir I can refer to the module with . or ./

bun install -g .

The command cowsay should now be globally available.

What do you see instead?

When running

bun install -g .

We get the error

bun add v1.0.1 (31aec4eb)

error: MissingPackageJSON

note: error occured while resolving .

Additional information

Bun for the win!

[Electroid]

Thanks for reporting, we likely aren't handling . correctly.

[masterujjval]

run bun install -g do not use .

[fregante]

This might be slightly related to #5483

The error is the same: bun does not support installing local modules that end up using the file: protocol.

[mikesprague]

FWIW, I've had the same problem with no file: prefix.

Example:

"bin": {
  "my-cli": "./src/cli/index.ts"
},

[effulgentsia]

Bun does not support installing local modules that end up using the file: protocol

Another manifestation of this error is if my package.json contains:

"dependencies": {
  "foo": "^1",
  "bar": "file:node_modules/foo/bar"
}

then bun install errors with:

error: MissingPackageJSON
note: error occured while resolving bar

My use case for this is if the foo package contains a subpackage bar, where bar has additional dependencies that aren't in foo. Not sure if there's another way to achieve that without using the file: protocol.

[fregante]

My use case for this is if the foo package contains a subpackage bar, where bar has additional dependencies that aren't in foo.

That sounds like a really bad module and you should send a PR to fix it. What you're suggesting shouldn't really work because node_module does not exist when reading the dependency list for the first time, so that path should not be resolved.

[effulgentsia]

What you're suggesting shouldn't really work because node_module does not exist when reading the dependency list for the first time

It works with npm if you do npm install; npm install, because then it exists for the second install. Definitely not elegant, but it does work.

That sounds like a really bad module and you should send a PR to fix it.

Thanks for the tip. I can do that, but that means adding the subpackage dependencies to the main package, right? Which means that users of the package have to install those dependencies even if they don't need to use the subpackage. Is that actually the common practice for packages with optional subpackages?