bundlebun 0.2.2.1.3.4-x86_64-darwin → 0.2.3.1.3.5-x86_64-darwin

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 14c2c109f6469a34a71685ad562a7a0b5e8f3aa792fb38791f1b2ddc10b79de6
-  data.tar.gz: b3121b0fd3f4cf7fb7c1cea258c8c4ea46ab20c238275ebf5aa1f77c2ac1246a
+  metadata.gz: a1a4e08be4fd7fd4ebd783deb9eb844925b8b724db52b2c3c0726acf5c3a73c2
+  data.tar.gz: d965a57e9077b5ea68f4475098980503fb10ecfdb8eaac9b953addf66afc1f47
 SHA512:
-  metadata.gz: 0163d0eb2dfde65c9084532f29084c681da17ad494d6e7fa29925d476400ca33bc564478752995926bb045d7aec660449ef465154e5a2ae67eb5a8ab23f5894a
-  data.tar.gz: 3686c203c62012ede29d79fe41714402e98eaa8a4892187dd3644632a6a7f892297f52603416dfd842bee71792a07a12a3459fa532351f78d5cdb04a886f0e38
+  metadata.gz: 359e9e9edb2318ba27f926603eee67221167a1663099deb00de8904d3e89cafdd6d8bc6be5d55f57b0ec56d59f1d32a8bf92632b27117e92eaf7f4e279707a97
+  data.tar.gz: c0fba334568b39c4d23727e9b621bc2fb17e8df55f3a3e3a0fd6be94aab01dc5d0b3cd6595327427c08b34a3253ea704ec510895bff9bfeefc022e38ba943434

data/CHANGELOG.md

@@ -1,3 +1,8 @@
+## [0.2.3] - 2025-12-17
+
+- Update dependencies
+- Minor documentation changes
+
 ## [0.2.2] - 2025-12-07
 
 - Bundler 4.0 spec fixes

data/README.md

@@ -9,6 +9,21 @@
   <img src="https://raw.githubusercontent.com/yaroslav/bundlebun/refs/heads/main/assets/mr-bundlebun-512.png" width="256" height="256" alt="Mr. Bundlebun">
 </div>
 
+## Rationale
+
+**Modern frontend setup is needlessly complex** and may involve a lot of maintenance. Developers need _at the very least_ a JavaScript runtime (typically, Node.js), a package manager (could be npm, yarn, or pnpm), and a build tool (Vite, Webpack, esbuild, Parcel—dozens of them).
+
+- One way forward is to dockerize development environments, creating unnecessary headaches for the development team—both frontend and backend engineers (especially if the team is not that large and the project is not that complex).
+- Another approach is to declare front-ops bankruptcy and pursue the "no-build" route.
+
+**What if we could simplify this?** **Bun** is a **JavaScript runtime**, optimized for speed and developer experience. Bun is _also_ a fast JavaScript **package manager**. Bun is _also_ a **build tool**. Bun is also distributed as a single executable file.
+
+However, Bun still requires [some installation](https://bun.sh/docs/installation), and we need to make sure everyone on the team is using the same version.
+
+So, how about we just pack it into a Ruby gem as a binary and allow developers to stay updated? Then, we'll be ready every time a new Bun version is out—or the user can freeze their desired version within their Ruby project. There are no setups, large READMEs with instructions, and no enforcing the Docker workflow.
+
+**Enter bundlebun**. With a fast JavaScript runtime and a package manager included, you can even skip the build tool and use Bun itself.
+
 ## Quickstart
 
 Starting with your Ruby or Rails project, no Bun or anything like that required:
@@ -28,21 +43,6 @@ Usage: bun <command> [...flags] [...args]
 ...
 ```
 
-## Rationale
-
-**Modern frontend setup is needlessly complex** and may involve a lot of maintenance. Developers need _at the very least_ a JavaScript runtime (typically, Node.js), a package manager (could be npm, yarn, or pnpm), and a build tool (Vite, Webpack, esbuild, Parcel—dozens of them).
-
-- One way forward is to dockerize development environments, creating unnecessary headaches for the development team—both frontend and backend engineers (especially if the team is not that large and the project is not that complex).
-- Another approach is to declare front-ops bankruptcy and pursue the "no-build" route.
-
-**What if we could simplify this?** **Bun** is a **JavaScript runtime**, optimized for speed and developer experience. Bun is _also_ a fast JavaScript **package manager**. Bun is _also_ a **build tool**. Bun is also distributed as a single executable file.
-
-However, Bun still requires [some installation](https://bun.sh/docs/installation), and we need to make sure everyone on the team is using the same version.
-
-So, how about we just pack it into a Ruby gem as a binary and allow developers to stay updated? Then, we'll be ready every time a new Bun version is out—or the user can freeze their desired version within their Ruby project. There are no setups, large READMEs with instructions, and no enforcing the Docker workflow.
-
-**Enter bundlebun**. With a fast JavaScript runtime and a package manager included, you can even skip the build tool and use Bun itself.
-
 ## Install
 
 bundlebun gem releases include a binary distribution of Bun for each supported Bun platform (macOS, Linux, Windows) and architecture. bundlebun is tested for Unix-like environments and Windows.
@@ -52,6 +52,10 @@ First, add it to your `Gemfile`. Make sure to add it _after_ your existing front
 ```ruby
 # ...
 
+# Frontend-related gems go here
+# For example, Vite integration
+# gem "vite_rails"
+
 gem "bundlebun"
 ```
 
@@ -68,21 +72,7 @@ bundle add bundlebun
 ```
 
 If you're seeing a message like `Could not find gems matching 'bundlebun' valid for all resolution platforms
-(aarch64-linux, aarch64-linux-gnu <...> )`, this may be [a known issue with Bundler/`Gemfile.lock`](https://www.google.com/search?client=firefox-b-d&q=Could+not+find+gems+matching+all+resolution+platforms) which you can fix. Open `Gemfile.lock` in your text editor, find a section called `PLATFORMS`, and alter a list of platforms you need to support. This can be a good default for most if you're targeting Linux and macOS (for Windows, also leave entries with `x64_mingw`):
-
-```
-(rest of the file here)
-
-PLATFORMS
-  aarch64-linux
-  arm64-darwin
-  x86_64-darwin
-  x86_64-linux
-
-(rest of the file here)
-```
-
-... and try `bundle install` again.
+(aarch64-linux, aarch64-linux-gnu <...> )`, [check this article](https://github.com/yaroslav/bundlebun/wiki/Could-not-find-gems-matching-'bundlebun'-valid-for-all-resolution-platforms).
 
 Next, run:
 
@@ -107,7 +97,25 @@ Next, the Rake task will try to detect the integrations we need to install based
 
 Usually, if you've placed `gem 'bundlebun'` after your frontend-related gems in the `Gemfile`, and did `rake bun:install`, the integrations should all be working out of the box.
 
-Alternatively, you can ensure an integration is loaded and the necessary modules are patched by calling methods that look like `Bundlebun::Integration::IntegrationName.bun!`: more on that below.
+Alternatively, you can ensure an integration is loaded and the necessary modules are patched by calling methods that look like `Bundlebun::Integration::IntegrationName.bun!`. See the API documentation for that.
+
+#### vite-ruby and vite-rails
+
+[vite-ruby](https://github.com/ElMassimo/vite_ruby) and [vite-rails](https://vite-ruby.netlify.app/) are gems that make Ruby and Rails integration with [Vite](https://vite.dev/), a great JavaScript build tool and platform, seamless and easy.
+
+The bundlebun integration would be installed automatically with `rake bun:install`, or you can run:
+
+```sh
+rake bun:install:vite
+```
+
+That will make sure you have a `bin/bun` binstub. Next, we'll install a custom `bin/bun-vite` binstub to use in build scripts. The installer Rake task will create a new `vite.json` file if it does not exist yet, or force the existing one to use that binstub for building. See the [Vite Ruby configuration manual](https://vite-ruby.netlify.app/config/index.html) for details on `vite.json`.
+
+Make sure you have `gem bundlebun` mentioned _after_ all the vite-related gems in your `Gemfile`. If you want to keep integrations to a minimum, and only enable them manually, use the following to manually turn on the bundlebun monkey-patching for vite-ruby:
+
+```ruby
+Bundlebun::Integrations::ViteRuby.bun!
+```
 
 #### Ruby on Rails: cssbundling and jsbundling
 
@@ -138,24 +146,6 @@ rake bun:install:bundling-rails
 
 The task makes sure a `bin/bun` binstub exists and installs an Rake task hack of sorts to ensure both build-related gems use our bundled version of Bun.
 
-#### vite-ruby and vite-rails
-
-[vite-ruby](https://github.com/ElMassimo/vite_ruby) and [vite-rails](https://vite-ruby.netlify.app/) are gems that make Ruby and Rails integration with [Vite](https://vite.dev/), a great JavaScript build tool and platform, seamless and easy.
-
-The bundlebun integration would be installed automatically with `rake bun:install`, or you can run:
-
-```sh
-rake bun:install:vite
-```
-
-That will make sure you have a `bin/bun` binstub. Next, we'll install a custom `bin/bun-vite` binstub to use in build scripts. The installer Rake task will create a new `vite.json` file if it does not exist yet, or force the existing one to use that binstub for building. See the [Vite Ruby configuration manual](https://vite-ruby.netlify.app/config/index.html) for details on `vite.json`.
-
-Make sure you have `gem bundlebun` mentioned _after_ all the vite-related gems in your `Gemfile`. If you want to keep integrations to a minimum, and only enable them manually, use the following to manually turn on the bundlebun monkey-patching for vite-ruby:
-
-```ruby
-Bundlebun::Integrations::ViteRuby.bun!
-```
-
 #### ExecJS
 
 [ExecJS](https://github.com/rails/execjs) runs JavaScript code straight from Ruby. To do so, it supports a bunch of runtimes it can launch—and get a result. The Bun runtime support already exists for ExecJS; we just need to ensure it uses the bundled one.
@@ -168,14 +158,6 @@ Alternatively, you can load the monkey-patch manually:
 Bundlebun::Integrations::ExecJS.bun!
 ```
 
-### Notes on `gem install`
-
-bundlebun is designed to be used with Bundler: installed in specific projects, and launched via `bin/bun` or integrations.
-
-If you install the gem globally, you _won't see the `bun` executable_ as a wrapper for a Ruby-bundled Bun runtime; instead, it would be called `bundlebun`.
-
-This naming discrepency is to avoid possible conflicts in your `$PATH` if you have an independent Bun runtime installed: if the directory with Ruby gem-generated binstubs is in your `$PATH` before the directory with your Bun runtime, running `bun` will launch the bundlebun's version, causing a lot of confusion. And that is why bundlebun is _not_ greedy with the `bun` executable name. If you wish to run Bun runtime globally using this gem, a simple symlink or a wrapper script will do, but the gem won't act destructively.
-
 ## Usage
 
 ### Binstub
@@ -191,10 +173,6 @@ Usage: bun <command> [...flags] [...args]
 ...
 ```
 
-### Return codes
-
-Note that with this (or any other option to run Bun), bundlebun will return the error code `127` if the executable is not found.
-
 ### `PATH`
 
 The bundlebun gem adds the directory with a binary Bun distribution to your `PATH`: prepends it there, to be exact. That helps existing tools that can detect the presence of `bun` executable to find it and work with no further setup or monkey-patching.
@@ -224,12 +202,7 @@ Bundlebun.call("outdated") # => `bun outdated`
 Bundlebun.call(["add", "postcss"]) # => `bun add postcss`
 ```
 
-Check out the [API documentation](https://rubydoc.info/gems/bundlebun) on `Bundlebun::Runner` for helper methods. Some of the most useful ones:
-
-- `Bundlebun::Runner.binary_path`: returns the full path to the bundled Bun library.
-- `Bundlebun::Runner.binary_path_exist?`: checks if that binary even exists.
-- `Bundlebun::Runner.binstub_exist?`: checks if the binstub exists.
-- `Bundlebun::Runner.binstub_or_binary_path`: returns the optimal way to run bundled Bun: a full path to binstub or a full path to the binary.
+Check out the [API documentation](https://rubydoc.info/gems/bundlebun) on `Bundlebun::Runner` for helper methods.
 
 ## Versioning
 

data/lib/bundlebun/version.rb

@@ -8,5 +8,5 @@ module Bundlebun
   # a Bun runtime with version `1.1.38`.
   #
   # This constant always points to the "own" version of the gem.
-  VERSION = '0.2.2'
+  VERSION = '0.2.3'
 end

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: bundlebun
 version: !ruby/object:Gem::Version
-  version: 0.2.2.1.3.4
+  version: 0.2.3.1.3.5
 platform: x86_64-darwin
 authors:
 - Yaroslav Markin