Rails ES6 based replacement for webpacker

rubyonrails-talk
1

DHH on replacing webpacker with a less heavy ES6 system:

7 Likes
2

I really like what I read, for me the JS part is by far the most painful. Having said that, Iā€™m afraid the transition from old apps could be a nightmare.

3 Likes
3

For sure Iā€™d appreciate Rails not having nodejs as a dependency.

But ā€¦ Seems like lots of people were exploring ditching sprockets and using webpack for all assets. Would the Rails community be doubling down on sprockets then for asset management?

Iā€™d have guessed there was a good chance the Rails community would embrace something like snowpack + rollup.

2 Likes
4

This is a good blog post, but in my opinion itā€™s just too early for this. I understand that DHH doesnā€™t want to switch from Webpacker to Vite or Snowpack because then there would be two integration gems (or three, counting Sprockets) that need to be supported. But in my opinion, this is wishful thinking. I believe Rails would be best served by adopting the excellent vite_ruby gem for Rails 7 and beyond and leave webpacker (and Sprockets!) behind. Instead this blog post basically tells me that weā€™re stuck with Webpacker for years, or need to use unsupported integration gems for the foreseeable future. This is understandable, but disappointing.

I outlined my opinion that Rails should adopt Vite in another thread: Webpacker - Bootstrap - JQuery, what am I doing wrong (and why so hard?) - #21 by evenreven

2 Likes
5

Please keep in mind that many people and many small/medium rails apps donā€™t want/need a large and complex JavaScript compiling system.

The WIP importmap gem gives Rails back a very simple, easy to understand JavaScript base. This should be the default.

Simultaneously webpacker is being improved and will be as simple as rails new my_app ā€”webpacker

As for other solutions, there will always be other solutions. Technology turns over fast.

Iā€™m probably not overly qualified to give this opinion but Iā€™m very excited for this.

3 Likes
6

Hi @DHH!

I have few questions regarding your article " Modern web apps without JavaScript bundling or transpiling":

Will Sprockets be favored for the non-JS asset processing that Webpack can do?

And Rails needs an answer for how to depend upon these packages and update them.

Should Rails be responsible for updating NPM packages to ESM? Does Skypack.dev solve that problem?

What about locking dependencies of dependencies? Thatā€™s a problem solved by the yarn.lock file.

In the interim, you can simply download these ESM packages and keep them locally in a vendor/ directory.

It would be great if Github (CC: @eileencodes) could offer a way to exclude directories from PRā€™s as loading PRs with vendor dependencies is a nightmare of slowness. Or maybe weā€™ll need a ā€œbest practiceā€ of always having two separate PRs for a change that includes vendor updates?

However, having dependencies stashed in an app is something that just doesnā€™t feel right in a git repo currently.

How about if the Rails build process (aka rake assets:precompile) would download the right versions of files so that the /vendor directory is populated at build time. Maybe you already have started working on this with this bit from the importmap-rails:

Rails.application.config.importmap.draw do
  pin "trix", to: "https://cdn.skypack.dev/trix"
  pin "md5", to: "https://cdn.skypack.dev/md5"
end
1 Like
7

Hey. Sprockets is great at making assets (JavaScript, CSS) available in a digested form from a common load path that can be accessed via gems. We never did solve that problem with Webpacker. So thatā€™s staying. But Iā€™d love to see a Sprockets Lite that essentially dumps all the JS compilation/source map/whatever stuff.

You can pin dependencies in the importmap to a specific version. If you load the floating skypack link (https://cdn.skypack.dev/md5), youā€™ll see:

/*
 * Skypack CDN - md5@2.3.0
 *
 * Learn more:
 *   šŸ“™ Package Documentation: https://www.skypack.dev/view/md5
 *   šŸ“˜ Skypack Documentation: https://www.skypack.dev/docs
 *
 * Pinned URL: (Optimized for Production)
 *   ā–¶ļø Normal: https://cdn.skypack.dev/pin/md5@v2.3.0-6tdhvfuY5owWhVhDHCz2/mode=imports/optimized/md5.js
 *   ā© Minified: https://cdn.skypack.dev/pin/md5@v2.3.0-6tdhvfuY5owWhVhDHCz2/mode=imports,min/optimized/md5.js
 *
 */

// Browser-Optimized Imports (Don't directly import the URLs below in your application!)
export * from '/-/md5@v2.3.0-6tdhvfuY5owWhVhDHCz2/dist=es2020,mode=imports/optimized/md5.js';
export {default} from '/-/md5@v2.3.0-6tdhvfuY5owWhVhDHCz2/dist=es2020,mode=imports/optimized/md5.js';

As you can see, those pinned URLs are tied to a specific version and intended for production.

Iā€™d love to see a method that downloads the pinned dependencies at some point, but itā€™s not trivial for packages that have nested dependencies, which havenā€™t been bundled into a single dist file.

The integration here is quite light touch in any case. Itā€™s just a set of default gems. So is --webpack. So someone can very easily add a vite setup that works the same way.

But for starting out a new Rails skeleton, Iā€™m keen that we donā€™t install 2,000 node_modules files and the rest of the node infrastructure into the app for those who can avoid it.

7 Likes