webpack-dev-server VS shakapacker

So I spent couple hours to sort the bug report out properly :) https://github.com/webpack/webpack-dev-server/issues/4890

Webpacker also includes webpack-dev-server, so we made it work as well. Since I had Simpacker installed, I only had to change the devServer part in webpack.config.js to make it work with npm scripts.

current setup doesn't provide us a developer friendly environment, we need to check the index.html file every time we make a change, to resolve this we'll use webpack-dev-server.

It looks like you don't have webpack-dev-server setup. That's what will allow you to have that seamless dev experience.

esbuild-loader (secret sauce!) fork-ts-checker-webpack-plugin (helps us with typechecking) nodemon-webpack-plugin (We can also use webpack-dev-server)

Webpack Dev Server provides a live reload feature without having you to build & wait.

webpack-dev-server - Development server for webpack

The migration guide https://github.com/shakacode/shakapacker/blob/master/docs/v6_upgrade.md looks like it's not too much work, I'll look into it. Still, I'd be interested about the security risks from using vulnerable packages for asset compilation.

For those of us who liked Webpacker: https://github.com/shakacode/shakapacker

There is an option to use Shakapacker

and finally to help your case as well: I would take one more step and replace webpacker with shakapacker. unfortunately in rails 7 the default js / css bundling is not based on webpack and they stopped supporting the original webpacker gem. shakapacker is a maintained successor to the webpacker gem with a better approach: they don't want to force you into writing yaml configs for something that wasn't meant to be a yaml file. also, it has way better defaults than webpacker used to have. then as soon as you got access to the real webpack configs, it'll be more clear where to look or what you need to add to the project.

webpacker -  Note that Webpacker has been retired, and it is not recommended for use unless you want the additional overhead and pain ;) That said, the folks over at ShakaCode are maintaining a fork named shakapacker

You should consider if you want to use Shakapacker (https://github.com/shakacode/shakapacker) for more JS intensive applications, or stick to the asset pipeline of jsbundling-rails. You can compare here: https://github.com/rails/jsbundling-rails/blob/main/docs/comparison_with_webpacker.md

and https://github.com/shakacode/shakapacker/pull/29

Here's the official fork: https://github.com/shakacode/shakapacker.

You can see an example of migration in this PR: https://github.com/shakacode/react_on_rails_tutorial_with_ss....

Thoughts?

Hey everybody, it's me Justin Gordon! I'm the maintainer of Shakapacker, the official successor to the "officially retired" Webpacker. The internal naming of Shakapacker is still webpacker. Upgrading is easy. You can see a comparison of the "new" jsbundling-rails with webpacker here: https://github.com/rails/jsbundling-rails/blob/main/docs/comparison_with_webpacker.md. Besides the many awesome improvements in v6 (almost all done as "Webpacker"), we've got an open PR to support SWC: https://github.com/shakacode/shakapacker/pull/29.