chokidar VS jsbundling-rails

For this, we'll use chokidar - more specifically the chokidar-cli package. chokidar is probably the most useful file watching library for the nodejs ecosystem and it will serve us well.

tailwindcss -> chokidar -> braces -> fill-range -> to-regex-range -> is-number

is-number was first published 9 years ago, when these kind of micro-packages were in vogue. braces was added as a dependency to chokidar over 6 years ago [1]. And if it ain't broke, don't fix it. I don't think the average JS dev today is going out and pulling in these deps.

[1] https://github.com/paulmillr/chokidar/commit/cbdf25563cfff7f...

The watching magic is really in the https://www.npmjs.com/package/chokidar library

> It’s typical to listen to this stream of events and use chained if-else statements to determine an action based on the type of the events that occur.

You'd think something like directory watching would have a clear set of events that would make nice objects with consistent meanings, but in my experience file watching gets crazy complicated, and can have all sorts of edge cases.

Just take a looked here for all the various edge cases that crop up: https://github.com/paulmillr/chokidar/issues

Then you have linux, windows, macos, and maybe you want to abstract over some underlying implementation like chokidar vs fb/watchman vs webpack/watchpack. Every new OS release could also cause things to change.

So usually its going to be a bunch of if-else statements hacked together to get around edge cases, and have to be revisited later on.

Any attempt to abstract this into objects, just obfuscates things. And OO forces you to name things, when in fact they might be un-nameable. `FileSystemModifyEventExceptWhenXAndYAndSometimesZ`.

The behavior might rely on a series of events together, so the object hierarchy must be re-worked.

OO has this rosy idea that we just have to come up with the perfect hierarchy, but things change in unexpected ways, and everything must have a descriptive noun.

Next, you can use a library like chokidar to listen for changes in your source directory. Create a ws server, and whenever a file changes, send a message.

As another has mentioned, nodemon uses chokidar under the hood for the actual file watching part.

At the end of the day, ironically, Nodemon does not even implement file watching functionality. It is a thin wrapper around chokidar (see source code), and the way it is being used is neither efficient (CPU and your battery usage) or performant. So it is not a false argument, just perhaps not the most appealing.

for file watching, it might use something similar to https://www.npmjs.com/package/chokidar

First, we need to install chokidar to enable watching and automatically refreshing our files.

I think this is more like a demo - you will not get the same features as jsbundling-rails by only following instructions in the video. For that you will need to change some other files as well. You can find out what files to be added/changed from the install script. The important bits are mostly the same as in the video, but some supplement parts are not mentioned in the video. Some people actually reported in the comment that they can't deploy such app, but I think it depends.

I'm sorry, I didn't see that in your title. Using esbuild is 100% supported by Rails through this gem https://github.com/rails/jsbundling-rails. Have a look at the docs there to make sure that you're setup correctly.

Rails applications are bundler-agnostic. They do not care how you bundle your javascript code. It just expects whatever comes from the bundler to be placed under app/assets, so the asset pipeline processes it. We can see this in the official jsbundling-rails gem, which consists of scripts to install different bundlers and configure a default npm build command to generate our bundles—no interaction whatsoever with the Rails configuration. This black-box bundler logic allows us to change and update our bundler system without tuning any other aspect of our Rails application.

Hello, this is my first time setting up a rails app that also uses react, I am using https://github.com/rails/jsbundling-rails I went with esbuild because I am following this tutorial on setting it up https://www.youtube.com/watch?v=yoLJXjEV2nM, however when I run bin/dev in the terminal I get the error bin/dev: 8: exec: foreman: not found

You first install your asset handlers as you need them for your project. They can be anything from rails/jsbundling-rails and rails/tailwindcss-rails to webpacker or something custom.

The functionality comes from https://github.com/rails/jsbundling-rails and https://github.com/rails/cssbundling-rails -- both come with Rails 7 and all you have to do is generate your app with the choices you want such as -j esbuild --css tailwind.

The Rails https://github.com/rails/jsbundling-rails gem lets you pick between esbuild, rollup and Webpack. If Turbopack ends up being popular then jsbundling should be able to support it.

The nice thing about Rails now is there's no direct integration like Webpacker once was. Now we can basically use the JS tool straight up and Rails will just look at assets in a specific directory, it doesn't matter what tool generated it.