This will ship as part of the Bun v1.2.19 release, which we are aiming for tonight.
There is a Windows-only bug in the isolated install mode blocking us from using isolated installs ourselves in the bun repo, and we need to fix that before we can release this.
If you want to try this early, you can run `bun upgrade --canary` and `bun install --linker=isolated` or put `install.linker = "isolated"` in bunfig.toml.
Isolated installs are a significant performance improvement on Windows (10x, sometimes 20x faster installs) and a minor positive or neutral performance impact on macOS and Linux. More importantly, they make using bun install in monorepos a lot more reliable by preventing dependencies from loading versions of other dependencies they did not specify in their own package.json.
Cool. Bun is already pretty fast on Windows, but I welcome more improvements. Thanks for all the great work!
FYI, there seems to be some bugs with installs yet that cause bun to crash. Might be related to having an old package-lock or old node_modules or switching back and forth between WSL and Windows proper. Bun just crashes. Deleting all lock files (bun and npms) and node modules usually fixes it.
Really loving Bun these days. Was really pleasantly surprised using their shell scripting API in typescript - single file, shebang line, straightforward DSL, support for piping data here and there.
Really, really nice and ergonomic. Made a few utility scripts today and enjoyed it much better than bash.
It is also my first choice now. Especially due to built in SQLite support. Also recently needed to write a simple script to dump some data to S3. Found out that bun has built in s3 client too...
I use Bun for many package.json projects, but for shell scripting specifically, I find that Deno is a better choice because you can use dependencies with just import statements via NPM or JSR.
#!/usr/bin/env -S deno run
import { z } from "npm:zod";
import { Webview } from "jsr:@webview/webview";
I just learned that Bun supports "autoimports" similar to the above.
> If no node_modules directory is found in the working directory or higher, Bun will abandon Node.js-style module resolution in favor of the Bun module resolution algorithm.
> Under Bun-style module resolution, all imported packages are auto-installed on the fly into a global module cache during execution (the same cache used by bun install).
Recently I migrated some small bash scripts to Js thanks to bunjs, chose it because its simplicity, speed and nice out-of-the-box features (db scripts without external deps). Quite happy with it, now I dont to relearn bash syntax every few months when I need to do some minor changes. Also, Javascript is prob the language that llvms understand the best which is a cool thing on these days.
So can I use bun now in pnpm monorepo without problems? I like bun and want to try it out more but also, I don't want to do the hassle of migrating only to find out some functionalities are missing eg. ability to run specific scripts on specific packages in monorepo.
> When using npm, all dependencies for a project are installed in a single node_modules directory. This means that if two packages depend on different versions of the same package, the one that is installed last will be used, which can lead to compatibility issues. This is known as "dependency hell" and can make it difficult to manage the dependencies of a project.
> pnpm's symlink feature addresses this problem by allowing different versions of the same package to be installed side-by-side, and linking them to their dependents through symlinks. This helps to ensure that the correct version of a package is used for each dependent, reducing the chances of compatibility issues and making it easier to manage dependencies.
This will ship as part of the Bun v1.2.19 release, which we are aiming for tonight.
There is a Windows-only bug in the isolated install mode blocking us from using isolated installs ourselves in the bun repo, and we need to fix that before we can release this.
If you want to try this early, you can run `bun upgrade --canary` and `bun install --linker=isolated` or put `install.linker = "isolated"` in bunfig.toml.
Isolated installs are a significant performance improvement on Windows (10x, sometimes 20x faster installs) and a minor positive or neutral performance impact on macOS and Linux. More importantly, they make using bun install in monorepos a lot more reliable by preventing dependencies from loading versions of other dependencies they did not specify in their own package.json.
Happy to answer any questions about Bun
Cool. Bun is already pretty fast on Windows, but I welcome more improvements. Thanks for all the great work!
FYI, there seems to be some bugs with installs yet that cause bun to crash. Might be related to having an old package-lock or old node_modules or switching back and forth between WSL and Windows proper. Bun just crashes. Deleting all lock files (bun and npms) and node modules usually fixes it.
Would it be possible to make the default behavior of the isolated linker "nohoist" the same as pnpm?
Bun is great, keep up the good work!
Really loving Bun these days. Was really pleasantly surprised using their shell scripting API in typescript - single file, shebang line, straightforward DSL, support for piping data here and there.
Really, really nice and ergonomic. Made a few utility scripts today and enjoyed it much better than bash.
https://bun.com/docs/runtime/shell
It is also my first choice now. Especially due to built in SQLite support. Also recently needed to write a simple script to dump some data to S3. Found out that bun has built in s3 client too...
I use Bun for many package.json projects, but for shell scripting specifically, I find that Deno is a better choice because you can use dependencies with just import statements via NPM or JSR.
I just learned that Bun supports "autoimports" similar to the above.
> If no node_modules directory is found in the working directory or higher, Bun will abandon Node.js-style module resolution in favor of the Bun module resolution algorithm.
> Under Bun-style module resolution, all imported packages are auto-installed on the fly into a global module cache during execution (the same cache used by bun install).
https://bun.sh/docs/runtime/autoimport
Recently I migrated some small bash scripts to Js thanks to bunjs, chose it because its simplicity, speed and nice out-of-the-box features (db scripts without external deps). Quite happy with it, now I dont to relearn bash syntax every few months when I need to do some minor changes. Also, Javascript is prob the language that llvms understand the best which is a cool thing on these days.
Llvms?
The next gen of compiler backends. They output binaries by infrering the most likely next token.
/s
So can I use bun now in pnpm monorepo without problems? I like bun and want to try it out more but also, I don't want to do the hassle of migrating only to find out some functionalities are missing eg. ability to run specific scripts on specific packages in monorepo.
Bun is slowly becoming the all-in-one solution for the js ecosystem, what a talented beast Jarred is
Main issue is "slowly"
Can someone explain what this does differently to the status quo under the hood?
> When using npm, all dependencies for a project are installed in a single node_modules directory. This means that if two packages depend on different versions of the same package, the one that is installed last will be used, which can lead to compatibility issues. This is known as "dependency hell" and can make it difficult to manage the dependencies of a project.
> pnpm's symlink feature addresses this problem by allowing different versions of the same package to be installed side-by-side, and linking them to their dependents through symlinks. This helps to ensure that the correct version of a package is used for each dependent, reducing the chances of compatibility issues and making it easier to manage dependencies.
From the last issue linked in the PR (https://github.com/oven-sh/bun/issues/1760)