`heroku buildpacks:add ...` will support any custom buildpacks - there's no use case for using `heroku-buildpack-multi` unless you are relying on a `.buildpacks` file to be present in the repo (which some older projects do).

In addition, https://github.com/ddollar/heroku-buildpack-multi is deprecated and is no longer being maintained. There is a maintained fork of the project at https://github.com/heroku/heroku-buildpack-multi but it isn't necessary to point people to this.

…e-redux-div-to-json-script

* origin/master: (42 commits)
  Release 6.5.1
  Update CHANGELOG.md
  Ability to work without sprockets (#671)
  Change Turbolinks unmount event from before-visit to before-render (#709)
  Update generator.md
  Update README.md
  Update i18n.md
  Small formatting tweak
  Release 6.5.0
  Updated CHANGELOG.md
  Update README.md
  Update README.md
  Update README.md
  Fix incorrect "this" references of Node.js SSR
  Remove reference to heroku-buildpack-multi (#698)
  Small fixes to achieve reproducible build (#661)
  Update PROJECTS.md
  Doc Changes for links on gitbook
  Update README.md
  Added property renderedHtml to return gen func
  ...

## Summary

- Wrap bundler commands in `install_generator.rb` with
`Bundler.with_unbundled_env` to prevent `BUNDLE_GEMFILE` inheritance
from the parent process
- Fixes "injected gems" conflicts when running `bundle exec rails g
react_on_rails:install`

## Problem

When executing `bundle exec rails g react_on_rails:install`, the
generator's internal bundler commands inherit the parent process's
`BUNDLE_GEMFILE` environment variable, causing gem version conflicts
with the error:

> "[!] There was an error parsing `injected gems`: You cannot specify
the same gem twice with different version requirements."

## Root Cause

Three `system()` calls in `install_generator.rb` execute bundler
commands without isolating the bundler environment:
- `system("bundle add shakapacker --strict")`
- `system("bundle install")`
- `system("bundle exec rails shakapacker:install")`

## Solution

Wrap bundler commands using `Bundler.with_unbundled_env`:

```ruby
success = Bundler.with_unbundled_env { system("bundle add shakapacker --strict") }
```

This is the official solution documented by:
- [Bundler Issue #698](rubygems/bundler#698)
- [Rails Issue #3153](rails/rails#3153)
- [Bundler exec
documentation](https://bundler.io/man/bundle-exec.1.html)

The pattern already exists in this codebase in `process_manager.rb` and
`pack_generator.rb`.

## Test plan

- [x] Verified fix clears `BUNDLE_GEMFILE` in child processes
- [x] Verified bundler discovers correct Gemfile in target app directory
- [x] RuboCop passes with no offenses

Fixes #2287

🤖 Generated with [Claude Code](https://claude.ai/code)

<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit

* **Chores**
* Ensure bundler commands run in an unbundled context so installation
tasks target the generated app’s Gemfile/Gemfile.lock, preventing
environment leakage and improving example app generation reliability.
  * Added clarifying comments about the bundler execution context.

* **Tests**
* Added regression tests to verify bundler environment isolation and
that local Gemfile/Gemfile.lock checks ignore inherited bundler
environment variables.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->

---------

Co-authored-by: Claude Opus 4.5 <[email protected]>
Co-authored-by: Justin Gordon <[email protected]>