rs-activeadmin-searchable_select 4.0.5

data/docs/propshaft-upgrade.md

@@ -0,0 +1,267 @@
+# Upgrading from Sprockets to Propshaft
+
+Propshaft has a smaller scope than Sprockets, therefore migrating to it will also require you to adopt the [jsbundling-rails](https://github.com/rails/jsbundling-rails) and [cssbundling-rails](https://github.com/rails/cssbundling-rails) gems. This guide will assume your project follows Rails 6.1 conventions of using [webpacker](https://github.com/rails/webpacker) to bundle javascript, [sass-rails](https://github.com/rails/sass-rails) to bundle css and [sprockets](https://github.com/rails/sprockets) to digest assets. Finally, you will also need [npx](https://docs.npmjs.com/cli/v7/commands/npx) version 7.1.0 or later installed.
+
+Propshaft depends on Rails 7, so you will need to upgrade to Rails 7+ before starting the migration.
+
+## 1. Migrate from Webpacker to jsbundling-rails
+
+Start by following these steps:
+
+1. Replace `webpacker` with `jsbundling-rails` in your Gemfile;
+2. Run `./bin/bundle install`;
+3. Run `./bin/rails javascript:install:webpack`;
+4. Remove the file `config/initializers/assets.rb`;
+5. Remove the file `bin/webpack`;
+6. Remove the file `bin/webpack-dev-server`;
+7. Remove the folder `config/webpack` (note: any custom configuration should be migrated to the new `webpack.config.js` file);
+8. Remove the file `config/webpacker.yml`;
+9. Replace all instances of `javascript_pack_tag` with `javascript_include_tag` and add `defer: true` to them.
+
+After you are done you will notice that the install step added various files to your project and updated some of the existing ones.
+
+**The new 'bin/dev' and 'Procfile.dev' files**
+
+The `./bin/dev` file is a shell script that uses [foreman](https://github.com/ddollar/foreman) and `Procfile.dev` to start two processes in a single terminal: `rails s` and `yarn build`. The latter replaces `webpack-dev-server` for bundling and watching for changes in javascript files.
+
+**The 'build' attribute added to package.json**
+
+This is the command that `yarn build` will use to bundle javascript files.
+
+**The new 'webpack.config.js' file**
+
+In `webpacker` this file was hidden inside the gem, but now you can edit it directly. If you had custom configuration in `config/webpack` you can move them to here. Projects with multiple entrypoints will need to adjust the `entry` attribute:
+
+```js
+module.exports = {
+  entry: {
+    application: "./app/javascript/application.js",
+    admin: "./app/javascript/admin.js"
+  }
+}
+```
+
+**The 'link_tree' directive added to 'app/assets/manifest.js'**
+
+This tells Sprockets to include the files in `app/assets/builds` during `assets:precompile`. This is the folder where `yarn build` will place the bundled files, so make sure you commit it to the repository and don't delete it when cleaning assets. 
+
+**What about babel?**
+
+If you would like to continue using babel for transpiling, you will need to configure it manually. First, open `webpack.config.js` and add this:
+
+```js
+module.exports = {
+  module: {
+    rules: [
+      {
+        test: /\.(js)$/,
+        exclude: /node_modules/,
+        use: ['babel-loader']
+      }
+    ]
+  }
+}
+```
+
+Then open `package.json` and add this:
+```json
+"babel": {
+  "presets": [
+    "./webpack.babel.js"
+  ]
+}
+```
+
+Finally, download [webpackers babel preset](https://github.com/rails/webpacker/blob/master/package/babel/preset.js) file and place it in the same directory as `package.json` with the name `webpack.babel.js`.
+
+**Module resolution**
+
+Webpacker included the `source_path` (default: `app/javascript/`) into module resolution, so a statement like `import 'channels'` imported `app/javascript/channels/`. After migrating to `jsbundling-rails` this is no longer the case. You will need to update your `webpack.config.js` to include the following if you wish to maintain that behavior:
+
+```javascript
+module.exports = {
+  // ...
+  resolve: {
+    modules: ["app/javascript", "node_modules"],
+  },
+  //...
+}
+```
+
+Alternatively, you can change modules to use relative imports, for example:
+```diff
+- import 'channels'
++ import './channels'
+```
+
+### Extracting Sass/SCSS from JavaScript
+
+In webpacker it is possible to extract Sass/SCSS from JavaScript by enabling `extract_css` in `webpacker.yml`. This allows for including those source files in JavaScript, e.g. `import '../scss/application.scss`
+
+If you wish to keep this functionality follow these steps:
+
+1. Run `yarn add mini-css-extract-plugin sass sass-loader css-loader`;
+2. Update your `webpack.config.js` to require `mini-css-extract-plugin` and configure the loaders (see example below).
+
+Example `webpack.config.js`:
+
+```javascript
+const path    = require("path")
+const webpack = require("webpack")
+const MiniCssExtractPlugin = require("mini-css-extract-plugin")
+
+module.exports = {
+  mode: "production",
+  devtool: "source-map",
+  entry: {
+    application: "./app/javascript/application.js"
+  },
+  resolve: {
+    modules: ["app/javascript", "node_modules"],
+  },
+  output: {
+    filename: "[name].js",
+    sourceMapFilename: "[file].map",
+    path: path.resolve(__dirname, "app/assets/builds"),
+  },
+  plugins: [
+    new MiniCssExtractPlugin(),
+    new webpack.optimize.LimitChunkCountPlugin({
+      maxChunks: 1
+    })
+  ],
+  module: {
+    rules: [
+      {
+        test: /\.s[ac]ss$/i,
+        use: [MiniCssExtractPlugin.loader, "css-loader", "sass-loader"],
+      },
+    ],
+  },
+}
+```
+
+## 2. Migrate from sass-rails to cssbundling-rails
+
+Note: if your application used Webpacker's `extract_css` to build your CSS and did not require `sass-rails`, you can skip this section.
+
+Start by following these steps:
+
+1. Add `cssbundling-rails` to your Gemfile;
+2. Run `./bin/bundle install`;
+3. Run `./bin/rails css:install:sass`.
+
+After you are done you will notice that the install step updated some files.
+
+**The new process in 'Procfile.dev'**
+
+Just like the javascript process, this one will bundle and watch for changes in css files.
+
+**The 'build:css' attribute added to package.json**
+
+This is the command `yarn build` will use to bundle css files.
+
+**The 'link_tree' directive removed from 'app/assets/manifest.js'**
+
+Now that the CSS files will be placed into `app/assets/build`, Sprockets no longer needs to worry about the `app/assets/stylesheets` folder. If you have any other `link_tree` for css files, remove them too.
+
+### Configuring multiple entrypoints
+
+Sprockets will only compile files in the root directories listed in `manifest.js`, but the sass package that `yarn build` uses will also check subfolders, which might cause compilation errors if your scss files are using features like `@import` and variables. This means that if you have multiple entry points in your app, you have some extra work ahead of you. 
+
+Let's assume you have the following structure in your `app/asset/stylesheets` folder:
+
+```
+stylesheets/admin.scss
+stylesheets/admin/source_1.scss
+stylesheets/admin/source_2.scss
+stylesheets/application.scss
+stylesheets/application/source_1.scss
+stylesheets/application/source_2.scss
+```
+
+Start by your separating your entrypoints from your other files, and adjusting all `@import` for the new structure:
+
+```
+stylesheets/entrypoints/admin.scss
+stylesheets/entrypoints/application.scss
+stylesheets/sources/admin/source_1.scss
+stylesheets/sources/admin/source_2.scss
+stylesheets/sources/application/source_1.scss
+stylesheets/sources/application/source_2.scss
+```
+
+Then adjust the `build` attribute in `package.json`:
+```
+"build:css": "sass ./app/assets/stylesheets/entrypoints:./app/assets/builds --no-source-map --load-path=node_modules"
+```
+
+### Deprecation warnings
+
+Sass might raise deprecation warnings depending on what features you are using (such as division), but the messages will explain how to fix them. If you are not sure, see more details in the [official documentation](https://sass-lang.com/documentation/breaking-changes).
+
+## 3. Migrate from Sprockets to Propshaft
+
+Start by following these steps:
+
+1. Remove `sprockets`, `sprockets-rails`, and `sass-rails` from the Gemfile and add `propshaft`;
+2. Run `./bin/bundle install`;
+3. Check your `Gemfile.lock`, repeat steps 1 and 2 for gems that list `sprockets` or `sprockets-rails` as a dependency;
+4. Open `config/application.rb` and remove `config.assets.paths << Rails.root.join('app','assets')`;
+5. Remove `app/assets/config/manifest.js`.
+6. Replace all asset_helpers (`image_url`, `font_url`) in css files with standard `urls`.
+7. If you are importing only the frameworks you need (instead of `rails/all`), remove `require "sprockets/railtie"`;
+
+### Asset paths
+
+Propshaft will automatically include in its search paths the folders `vendor/assets`, `lib/assets` and `app/assets` of your project and of all the gems in your Gemfile. You can see all included files by using the `reveal` rake task:
+```
+ rake assets:reveal
+```
+
+### Asset helpers
+
+Propshaft does not rely on asset_helpers (`asset_path`, `asset_url`, `image_url`, etc.) like Sprockets did. Instead, it will search for every `url` function in your css files, and adjust them to include the digest of the assets they reference.
+
+Go through your css files, and make the necessary adjustments:
+```diff
+- background: image_url('hero.jpg');
++ background: url('/hero.jpg');
+```
+
+Notice that Propshaft's version starts with an `/` and Sprockets' version does not? That's because the latter uses **absolute paths**, and the former uses **relative paths**. To better illustrate that difference, let's assume you have the following structure:
+
+```
+assets/stylesheets/theme/main.scss
+assets/images/hero.jpg
+```
+
+In Sprockets, `main.scss` can reference `hero.jpg` like this:
+```css
+background: image_url('hero.jpg')
+```
+
+Using the same path with `url` in Propshaft will cause it to raise an error, saying it cannot locate `theme/hero.jpg`. That's because Propshaft assumes all paths are relative to the path of the file it's processing. Since it was processing a css file inside the `theme` folder, it will also look for `hero.jpg` in the same folder.
+
+By adding a `/` at the start of the path we are telling Propshaft to consider this path as an absolute path. While this change in behavior increases the work a bit when upgrading, it makes **external libraries like FontAwesome and Bootstrap themes work out-of-the-box**.  
+
+### Asset content
+
+It's a common pattern in apps to inline small SVG files and low resolution versions of images that need to be displayed as quickly as possible. In Propshaft, the same line of code works for all environments: 
+```ruby
+Rails.application.assets.load_path.find('logo.svg').content
+```
+
+As Rails escapes html tags in views by default, in order to output a rendered svg you will need to specify rails not to escape the string using [html_safe](https://api.rubyonrails.org/classes/String.html#method-i-html_safe) or [raw](https://api.rubyonrails.org/classes/ActionView/Helpers/OutputSafetyHelper.html#method-i-raw).
+```ruby
+Rails.application.assets.load_path.find('logo.svg').content.html_safe
+raw Rails.application.assets.load_path.find('logo.svg').content
+```
+
+### Precompilation in development
+
+Propshaft uses a dynamic assets resolver in development mode. However, when you run `assets:precompile` locally Propshaft will then switch to a static assets resolver. Therefore, changes to assets will not be observed anymore and you will have to precompile the assets each time changes are made. This is different to Sprockets.
+
+If you wish to have dynamic assets resolver enabled again, you need to clean your target folder (usually `public/assets`) and propshaft will start serving dynamic content from source.  One way to do this is to run `rails assets:clobber`.
+
+Another way to watch changes in your CSS & JS assets is by running `bin/dev` command instead of `rails server` that not only runs the server but also keeps looking for any changes in the assets and once it detects any changes, it compiles them while the server is running. This is possible because of the `Procfile.dev`.

data/docs/rails-7-asset-pipeline.md

@@ -0,0 +1,279 @@
+## [](https://discuss.rubyonrails.org/t/guide-to-rails-7-and-the-asset-pipeline/80851#intro-1)Intro
+
+Rails 7 brought with it an overhaul of the Asset Pipeline in the form of multiple new gems that either introduced a new way of handling assets (importmaps-rails), or broke down existing gems (propshaft, jsbundling-rails, cssbundling-rails) into smaller parts that make use of existing standalone tools and therefore support modern features that were previously unavailable.
+
+## ActiveAdmin Trumbowyg Integration
+
+**Important**: As of version 2.0, this gem **no longer supports Sprockets**. You must use a modern JavaScript bundler (esbuild, webpack, or similar) with Rails 7+.
+
+### Installation with Modern Bundlers (esbuild/webpack)
+
+1. Install the NPM package:
+   ```bash
+   npm install @rocket-sensei/activeadmin_trumbowyg
+   ```
+
+2. Import the package in your JavaScript entrypoint (e.g., `app/javascript/application.js`):
+   ```javascript
+   import '@rocket-sensei/activeadmin_trumbowyg'
+   ```
+
+3. The package automatically:
+   - Registers the Trumbowyg editor with ActiveAdmin
+   - Loads all required styles
+   - Configures the editor for `ActiveAdmin.FormBuilder`
+
+### JavaScript Module Structure
+
+The NPM package exports JavaScript modules from the `active_admin/` namespace:
+- `active_admin/trumbowyg.js` - Main editor initialization
+- `active_admin/init.js` - ActiveAdmin integration setup
+
+### Migration from Sprockets
+
+If you're upgrading from an older version that used Sprockets:
+
+1. Remove any Sprockets require directives:
+   ```javascript
+   // Remove these lines:
+   //= require activeadmin/trumbowyg
+   //= require activeadmin/init
+   ```
+
+2. Remove the gem's assets from your Sprockets manifest
+3. Install via NPM and import as shown above
+4. Ensure you're using jsbundling-rails, propshaft, or similar modern asset handling
+
+While a few of these gems are still in pre-release status, their maintainers, contributors and early adopters have already deployed them to production. However, widespread adoption is currently being hampered by the lack of detailed documentation and some missing features that would allow them to support more use cases.
+
+With the creation of the new Rails Discord channel for people interested in contributing to Rails, I think it’s a good time to coordinate with the community so we can pare down the rough edges. Therefore I’d like to start this thread so we can make a more visible demonstration that there are people working to improve things and provide central source of knowledge while all the related guides haven’t been updated.
+
+**If you want the TL:DR version of this guide, check “What will Rails recommend going forward?” further down.**
+
+**This is a work in progress**
+
+## [](https://discuss.rubyonrails.org/t/guide-to-rails-7-and-the-asset-pipeline/80851#four-approaches-to-the-asset-pipeline-2)Four approaches to the Asset Pipeline
+
+-   Sprockets: The original asset pipeline gem, built for the HTTP/1 era and low javascript frontends. It handled the bundling and digesting of javascript, css and image files, without relying on node packages.
+    
+-   Webpacker/Shakapacker: Shipped with Rails 5.2, as a wrapper around the complexity of Webpack/Node/Yarn, this gem could completely replace Sprockets or simply take over javascript transpiling and bundling. It provided Rails “out of the box” support for SPA frameworks like React.
+    
+-   Import Maps: Shipped with Rails 7.0, it replaces Sprockets as the default asset pipeline gem. Although it eliminates the need for node/yarn and other complex tooling, it requires the application using it to be deployed in an environment that supports HTTP/2, otherwise it causes severe performance problems.
+    
+-   Bundling gems: Shipped with Rails 7.0, the multiple bundling gems provide a more traditional, if more modern, approach to the asset pipeline than import maps does. They basically break down the “all in one” approach of Sprockets into multiple smaller, specialized pieces. The main gems are propshaft, jsbundling and cssbundling.
+    
+
+## [](https://discuss.rubyonrails.org/t/guide-to-rails-7-and-the-asset-pipeline/80851#explanations-and-recommendations-3)Explanations and recommendations
+
+I’m writing this not as maintainer of any of these gems, but as a regular contributor and someone who has deployed most of them in the monolithic production app that my own company relies on. Corrections and suggestions are welcome.
+
+### [](https://discuss.rubyonrails.org/t/guide-to-rails-7-and-the-asset-pipeline/80851#sprockets-4)Sprockets
+
+-   Status: Maintained (but **NOT supported by activeadmin_trumbowyg**)
+    
+-   Notes: Several fixes and updates are only available in the edge version.
+    
+
+The original asset pipeline gem, Sprockets provides bundling and digesting for javascript, css and image files. Built before node was widely adopted, Sprocket's "everything included" approach worked well for many years. However, as frontend programming became more complex, it started to fall behind dedicated tools like webpack. It was the only officially supported gem up to Rails 5.2, when Webpacker was introduced, and remained the default until Rails 7, when it was replaced by Import Maps.
+
+**Important for activeadmin_trumbowyg users**: This gem no longer supports Sprockets. You must use a modern JavaScript bundler with the NPM package `@rocket-sensei/activeadmin_trumbowyg`.
+
+**If you are learning Rails**: Don't use it. Your time will be better spent learning one of the more modern approaches.
+
+**If you are starting a new app**: Only if you absolutely do not want to deal with node/yarn and are not ready for import maps. Note that activeadmin_trumbowyg will not work with Sprockets.
+
+**If you have an existing app with Sprockets**: You can continue using it for other assets, but you'll need to migrate to a modern bundler to use activeadmin_trumbowyg. Sprockets will receive maintenance updates at least until Propshaft reaches 1.0, and probably longer.
+
+### [](https://discuss.rubyonrails.org/t/guide-to-rails-7-and-the-asset-pipeline/80851#webpacker-5)Webpacker
+
+-   Status: Retired
+    
+-   Notes: All work done for the unreleased version 6 went to Shakapacker.
+    
+
+Rails has always had a complicated relationship with vanilla javascript, and to get around perceived limitations of the language, it adopted coffeescript as the default. Things changed with the arrival of ES6 and Babel for transpilation, but getting everything working so that you could use modern features of the language while remaining compatible with older browsers was difficult. Webpacker was created to solve that problem and for some time provided the bridge for developers interested in investing more heavily in the javascript ecosystem.
+
+Five years later, all browsers oficially support ES6, so transpilation was no longer necessary and the extra complexity not worth for many developers. This lead to Webpacker being retired.
+
+**If you are learning Rails**: Don’t use it. If your plan is to build your frontend entirely with Rails and Hotwired, then import maps is the preferred approach. However if your plan is to use a framework like React, then Shakapacker is the official sucessor and includes all the nice things that most javascript developers expect.
+
+**If you are starting a new app**: Don’t use it. SPAs should go with Shakapacker, the official sucessor of Webpacker, which supports things like HMR. Hotwired/Tailwind based apps should go with importmaps-rails, or the bundling gems, which let you to choose your preferred bundling tool (esbuild, postcss, etc.).
+
+**If you have an existing app with Webpacker**: Give some serious consideration to replacing it. If your app is a SPA, specially a React one, then Shakapacker is your friend, as it’s the official sucessor to Webpacker. If you are mostly using Hotwired and doing server side rendering, jsbundling-rails + webpack is an easy migration (and you can later migrate to the excellent esbuild).
+
+### [](https://discuss.rubyonrails.org/t/guide-to-rails-7-and-the-asset-pipeline/80851#import-maps-6)Import maps
+
+-   Status: Released, in active development
+    
+-   Notes: A shim is available to provide support for older browsers.
+    
+
+Rails 7 apps defaults to the importmaps-rails gem, which shares the same name as the import maps feature in browsers. This gem relies on the trifecta of HTTP2 (which eliminates the penalty of many small files), wide spread support for ES6 and the import map feature (which can the added to legacy browsers and Safari through a shim).
+
+**If you are learning Rails**: This is the preferred approach, but only if you plan on building your frontends with Rails/Hotwired. If you want to use React/Vue/etc. then go with Shakapacker.
+
+**If you are starting a new app**: Is it an SPA or your planned production environment only support HTTP1? This is not your friend, go with Shakapacker or the bundlings gems. However, if you are on the Hotwired team and have Cloudflare or Nginx in front of your Puma servers, then sure!
+
+**If you have an existing app**: Stay where you are. This is a very different approach to handling javascript and css files and will require extensive work to migrate, specially if you have a lot of frontend code or rely on many node packages.
+
+### [](https://discuss.rubyonrails.org/t/guide-to-rails-7-and-the-asset-pipeline/80851#propshaft-7)Propshaft
+
+-   Status: Alpha, in active development
+    
+-   Notes: Already deployed to production in Basecamp (and by me, FWIW).
+    
+
+The sucessor to Sprockets, it has a much smaller scope than its predecessor: it’s only handles digesting, fixin references in css files so they use the digested filename, and moving everything to the public folder.
+
+This means that any setup using propshaft will also be using one or more of the new bundlings gems, probably jsbundling-rails and cssbundling-rails.
+
+**If you are learning Rails**: Don’t use it. It has no documentation, very few users and is still in alpha. You are already going to be spending a lot of effort learning other things, no need to make your life harder.
+
+**If you are starting a new app**: Stick to import maps if you are going with Hotwired or shakapacker if you are going with React.
+
+**If you have an existing app**: Maybe. It should be an easy migration for apps that are running Sprockets (CSS and digests) and Webpacker (javascript) and will also allow you to later webpack with the phenomenal esbuild. Just make sure you are comfortable running pre-release code with almost zero documentation in production. For what is worth, I’m using it in production and so is Basecamp.
+
+### [](https://discuss.rubyonrails.org/t/guide-to-rails-7-and-the-asset-pipeline/80851#jsbundling-rails-8)jsbundling-rails
+
+-   Status: Released, in active development
+    
+-   Notes: **Recommended for activeadmin_trumbowyg users**
+    
+
+Provides javascript bundling features that were previously handled by Sprockets and Webpacker. Supports webpack, esbuild and rollup.
+
+**For activeadmin_trumbowyg users**: This is the recommended approach. Install the NPM package with `npm install @rocket-sensei/activeadmin_trumbowyg` and import it in your JavaScript entrypoint.
+
+**If you are learning Rails**: This is a good choice if you need npm packages or complex JavaScript features.
+
+**If you are starting a new app**: Excellent choice for apps that need npm packages, including activeadmin_trumbowyg.
+
+**If you have an existing app**: Great migration path from Webpacker or Sprockets, especially for activeadmin_trumbowyg integration.
+
+### [](https://discuss.rubyonrails.org/t/guide-to-rails-7-and-the-asset-pipeline/80851#cssbundling-rails-9)cssbundling-rails
+
+-   Status: Released, in active development
+    
+-   Notes:
+    
+
+Provides css bundling features that were previously handled by Sprockets and Webpacker. Supports Tailwind, Bootstrap, Bulma, PostCSS and Dart Sass.
+
+**If you are learning Rails**:
+
+**If you are starting a new app**:
+
+**If you have an existing app**:
+
+### [](https://discuss.rubyonrails.org/t/guide-to-rails-7-and-the-asset-pipeline/80851#dartsass-rails-10)dartsass-rails
+
+-   Status: Released, in active development
+    
+-   Notes:
+    
+
+Same as cssbundling-rails, but specific for dart. A wrapper around the platform specific versions of dart, instead of the yarn versions.
+
+**If you are learning Rails**:
+
+**If you are starting a new app**:
+
+**If you have an existing app**:
+
+### [](https://discuss.rubyonrails.org/t/guide-to-rails-7-and-the-asset-pipeline/80851#what-will-rails-recommend-going-forward-11)What will Rails recommend going forward?
+
+The default (no node/yarn):
+
+-   Rails 7: Import Maps + Sprockets
+-   Rails 8: Import Maps + Propshaft
+
+The alternative way (with node/yarn and your choice of bundler):
+
+-   Rails 7: Bundling Gems\* + Sprockets
+-   Rails 8: Bundling Gems\* + Propshaft
+
+\* Bundling gems are `cssbundling-rails`, `jsbundling-rails`, etc.
+
+### [](https://discuss.rubyonrails.org/t/guide-to-rails-7-and-the-asset-pipeline/80851#github-pages-12)Github Pages
+
+-   [Sprockets](https://github.com/rails/sprockets)
+    
+-   [Propshaft](https://github.com/rails/propshaft/)
+    
+-   [Shakapacker](https://github.com/shakacode/shakapacker)
+    
+-   [importmap-rails](https://github.com/rails/importmap-rails)
+    
+-   [jsbundling-rails](https://github.com/rails/jsbundling-rails)
+    
+-   [cssbundling-rails](https://github.com/rails/cssbundling-rails)
+    
+-   [dartsass-rails](https://github.com/rails/dartsass-rails)
+    
+-   [tailwind-rails](https://github.com/rails/tailwindcss-rails)
+    
+
+### [](https://discuss.rubyonrails.org/t/guide-to-rails-7-and-the-asset-pipeline/80851#upgrade-guides-13)Upgrade Guides
+
+-   [From Turbolinks to Turbo](https://github.com/hotwired/turbo-rails/blob/main/UPGRADING.md)
+    
+-   [From Sprockets/Wepacker to Propshaft](https://github.com/rails/propshaft/blob/main/UPGRADING.md)
+    
+-   [From Webpacker to Shakapacker](https://github.com/shakacode/shakapacker/blob/master/docs/v6_upgrade.md)
+    
+
+### [](https://discuss.rubyonrails.org/t/guide-to-rails-7-and-the-asset-pipeline/80851#relevant-information-14)Relevant Information
+
+-   [Modern web apps without JavaScript bundling or transpiling](https://world.hey.com/dhh/modern-web-apps-without-javascript-bundling-or-transpiling-a20f2755)
+    
+-   [Introducing Propshaft](https://world.hey.com/dhh/introducing-propshaft-ee60f4f6)
+    
+
+### Complete ActiveAdmin Trumbowyg Setup Example
+
+For a new Rails 7+ app with ActiveAdmin and Trumbowyg:
+
+1. **Setup Rails with jsbundling and cssbundling:**
+   ```bash
+   rails new myapp -j esbuild -c bootstrap
+   cd myapp
+   ```
+
+2. **Add ActiveAdmin and activeadmin_trumbowyg gems:**
+   ```ruby
+   # Gemfile
+   gem 'activeadmin'
+   gem 'activeadmin_trumbowyg'
+   ```
+
+3. **Install the NPM package:**
+   ```bash
+   npm install @rocket-sensei/activeadmin_trumbowyg
+   ```
+
+4. **Import in your JavaScript entrypoint:**
+   ```javascript
+   // app/javascript/application.js
+   import '@rocket-sensei/activeadmin_trumbowyg'
+   ```
+
+5. **Use in your ActiveAdmin forms:**
+   ```ruby
+   # app/admin/posts.rb
+   form do |f|
+     f.inputs do
+       f.input :title
+       f.input :content, as: :trumbowyg
+     end
+     f.actions
+   end
+   ```
+
+**Note**: The JavaScript modules are now under the `active_admin/` namespace, not `activeadmin/`. The NPM package handles all initialization automatically when imported.
+
+### [](https://discuss.rubyonrails.org/t/guide-to-rails-7-and-the-asset-pipeline/80851#changelog-15)Changelog
+
+-   2022-06-17: First version
+-   2022-06-18: Added the 'Four approaches' section. Rewrote some explanations
+-   2022-06-28: Added "What will Rails recommend".
+-   2024-XX-XX: Added activeadmin_trumbowyg NPM package instructions and Sprockets deprecation notice