[HN Gopher] Rails 6 with Webpacker 6, Tailwind 2 with JIT, Postc...
___________________________________________________________________
Rails 6 with Webpacker 6, Tailwind 2 with JIT, Postcss 8 and some
default setup
Author : nauman
Score : 138 points
Date : 2021-08-15 12:33 UTC (10 hours ago)
(HTM) web link (nauman.medium.com)
(TXT) w3m dump (nauman.medium.com)
| paozac wrote:
| Useful recap. I went through something similar a few weeks ago
| and the webpack/tailwindcss JIT/postcss setup has been a pain in
| the ass: dependency hell, outdated documentation, unintelligible
| error messages.
|
| I'm glad to see that both rails and phoenix guys are looking for
| a way out of this madness. The writing is on the wall.
| ramesh31 wrote:
| What is Webpacker?
| meepmorp wrote:
| Webpack packaged for use in rails.
| cutler wrote:
| I think esbuild would have made webpack redundant soon if it
| hadn't already been removed.
| chana_masala wrote:
| There are enough instances of webpacker in this thread (instead
| of webpack) making me think it's something different.
| nickjj wrote:
| If anyone wants to see a working example of this in Docker, I
| have an example app at: https://github.com/nickjj/docker-rails-
| example
|
| Besides Rails / Webpacker 6 and Tailwind with the JIT compiler it
| also includes Sidekiq, Action Cable and Turbo along with Postgres
| and Redis.
|
| I'm not married to the idea of Webpacker, but currently it's the
| most painless way to create bundles and process your CSS and JS
| even if you mostly use server side templates with sprinkles of
| JS. I'll switch the example app to what Rails defaults to in the
| future but right now we're in a limbo state where combining a
| bunch of other independent watchers (esbuild + Tailwind's
| watcher) and ESM isn't a better development experience IMO.
|
| With Webpacker and Tailwind's JIT, CSS + JS changes take 100ms
| and you can further optimize startup times with using Webpack's
| disk cache. With the above Docker set up it's configured with
| multi-stage builds so your final Rails app only has the end
| result of running an assets precompile which only runs with
| RAILS_ENV=production. The Webpack watcher only runs in
| development too.
|
| If anyone works with Phoenix instead, a similar example app is
| here https://github.com/nickjj/docker-phoenix-example. There's
| also example apps for Flask, Django, Node and Play too if you
| replace the name of the repo. All of them go over the motions of
| setting up a base line app with Tailwind and Webpack plus
| whatever else is idiomatic in that stack.
|
| _Plot twist:_ For the Flask, Django, Phoenix, Node and Play
| examples I 've used nearly the same Webpack config for 2 years
| and I continuously keep Webpack and all of the JS dependencies up
| to date. There hasn't been any issues at all. I wouldn't consider
| myself an advanced front-end developer either. I glanced their
| docs, found something that works and stuck with it.
| Aeolun wrote:
| Wait. So... you practically need to develop an app to start
| developing an app?
|
| When someone tells me to 'invoke these 3 magic incantations', I
| can sort of keep track of it. But here it seems like the
| instructions are to invoke these 300 magic incantations.
| darwingr wrote:
| They are only generators. You don't need to use them but they
| are there if you choose to use them.
| kayodelycaon wrote:
| This is due to adding a JavaScript framework. Rails can be up
| and running immediately.
| tolien wrote:
| Yeah, one of the key selling points of Rails was that it was
| Omakase (Japanese: "I'll leave it up to you", i.e. you take the
| defaults Rails provides) and "batteries included" (i.e. there's
| enough provided in the box to get a working application).
|
| Having to jump through all these hoops (I'll note that one of
| the suggested gems is Devise, which provides a framework for
| user authentication) suggests either this is very much no
| longer the case or this is tacking on a lot of stuff Rails was
| never intended to use, which could be fun to maintain down the
| line.
| Mikeb85 wrote:
| Having just been playing around with Rails and different CSS
| frameworks for a new project, this is entirely due to
| Tailwind's dependencies. Adding other CSS frameworks is as
| easy as yarn add X then importing it into your
| application.css file.
| kayodelycaon wrote:
| The majority of hoops jumped through in the article are
| entirely of the writer's own making. They changed the default
| CSS pipeline and added functionality Rails deliberately does
| not define.
|
| Devise is common for user authentication (and good choice, in
| my opinion) but it is extremely opinionated and does not like
| you departing from the blessed path.
|
| Rails tends to avoid enforcing patterns beyond the base
| building blocks of MVC. User authentication is out of scope.
| (Turbo links is strongly opinionated but also very limited
| and very easy to remove.)
| tolien wrote:
| My point about Devise was more "if you're not using auth,
| why have you included this?". I think Rails should probably
| have a Devise-lite in the box, though.
|
| This sounds like the second of my options i.e. gl;hf when
| the next major Rails release comes around.
| dyeje wrote:
| Rails still works just fine out of the box. The bulk of this
| article is setting up Tailwind JIT, which is not required.
| jacobsenscott wrote:
| This setup is deviating quite a bit from a default rails
| setup: using the beta webpacker, tailwind + plugins, some
| extra gems.
|
| Also - I noticed the author says "foreman is the best way to
| develop locally". I encourage the author to give overmind a
| try - it is a drop in, more featureful replacement for
| foreman. I love it.
| adamwathan wrote:
| Creator of Tailwind here -- if you don't want to go deep into JS
| tooling and really just care about spitting out a CSS file, it's
| a lot simpler to just use our CLI tool:
| https://tailwindcss.com/docs/installation#using-tailwind-cli
| Mikeb85 wrote:
| Good to note!
| [deleted]
| AlchemistCamp wrote:
| Any plans for adding integration guides for back-end frameworks
| like Rails and Phoenix?
|
| It seems like Tailwind is popular enough now to support guides
| for more than just JS frameworks and Laravel :)
| pjm331 wrote:
| Love seeing the set of gems that folks tend to bring into all
| their projects. https://github.com/dejan/rails_panel Was a new
| one for me, will def be checking that out
| bouk wrote:
| I started work on a (webpacker-like) esbuild integration for
| Rails: https://github.com/bouk/esbuilder
|
| It works, but needs UX work, documentation and more extensive
| testing to be appropriate for general use
| gjmacd wrote:
| Another reason to move to Elixir from Ruby...
| anamexis wrote:
| Where setting up a new app with Tailwind JIT is substantially
| easier?
| gjmacd wrote:
| Where Phoenix does a better job with all this and you don't
| have Ruby's baggage anymore.
| anamexis wrote:
| What is "all this"? This post is almost entirely about
| setting up Tailwind.
|
| (I have developed professionally with both Rails and
| Phoenix and enjoy both.)
| gjmacd wrote:
| https://pragmaticstudio.com/tutorials/adding-tailwind-css-
| to...
| anamexis wrote:
| Right, this process looks basically equivalent in steps
| and complexity.
| Mikeb85 wrote:
| It's literally the same process and it still uses
| webpacker...
| joelbluminator wrote:
| Elixir isn't even in Tiobe's top 50
| https://www.tiobe.com/tiobe-index/
| cutler wrote:
| Whilst I agree with you that Elixir is an also-ran Tiobe is
| the worst yardstick by which to measure a programming
| language. I can never understand why anyone takes it
| seriously.
| joelbluminator wrote:
| Agreed. Redmonk then? Not in the top 20
| https://redmonk.com/sogrady/2021/08/05/language-
| rankings-6-2...
|
| I think Elixir fans should learn a lesson in being
| humble...
| kweinber wrote:
| Elixir is like the alternate town in Blazing Saddles. It looks
| great but you find out there aren't really people nor library
| depth there. After it blows up your staffing and project plans
| you end up moving back.
| MrMcDowall wrote:
| Yeah, Elixir is great, but zealots keep acting like it's
| happening, and it is totally not happening.
| cultofmetatron wrote:
| I built my startup in elixir. yes, there aren't as many
| libraries but the ones I've needed have been available and
| reasonably documented in most cases.
|
| one thing I like in elixir is that the whole language (and
| thus libraries) are more composable. its easier forme to
| break and reform functionality from libraries in ways the
| authors didnt envision. Takes more time to integrate but the
| end result is way more maintainable.
| toberoni wrote:
| It's telling that most instructions deal with the Javascript
| toolchain and not Rails itself. And let's hope that everything
| works and none of the 2000 imported node_modules blow up when
| this tutorial is 3 months old.
|
| I'm looking forward to Phoenix 1.6 which ditches Webpack for
| esbuild. Every step away from the insane churn of the modern
| frontend world is welcome.
| xdennis wrote:
| > I'm looking forward to Phoenix 1.6 which ditches Webpack for
| esbuild. Every step away from the insane churn of the modern
| frontend world is welcome.
|
| I don't like the churn either, but ditching X for Y only
| contributes to the churn.
| sedeki wrote:
| This is too broad to be true in general. It depends on what Y
| is...
| seanclayton wrote:
| Phoenix is the maintainer of the Elixir esbuild package--it's
| just a binary.
| joelbluminator wrote:
| Looks like Rails wants off Webpacker as well
| https://github.com/rails/importmap-rails
| CapriciousCptl wrote:
| I could be wrong but didn't phoenix just switch to webpack from
| some other package manager? I guess that was 3ish years ago so
| a lifetime more or less in JS.
| andruby wrote:
| Phoenix was using brunch until it switched to webpack in
| 1.4.0 (2018-11-07)
| sergiomattei wrote:
| I don't think it's telling of anything. Rails was not made to
| work seamlessly with these tools, so obviously there's going to
| be some setup cost.
|
| Compare with something like NextJS where the aforementioned
| setup takes almost no effort.
| Lapz wrote:
| How often does your webpack setup blow up? We haven't touched
| our configuration in a year and it still works perfectly fine.
| What complex things must you be doing for you config to not
| even last 3 months !!!
| toberoni wrote:
| 3 months might be (close to) hyperbole, but webpack/JS
| package management is a source of consistent pain. It sticks
| out like a sore thumb across my web stacks (PHP/WP, Ruby,
| Elixir) and its brittle complexity causes the most unpleasant
| dev experience I have to deal with.
|
| I doubt it's my incompetence alone - npm is involved in over
| 25% of Phoenix's issues!
| jakelazaroff wrote:
| Can't speak for the integration into non-JS ecosystems, but
| since I started using Create React App instead of rolling
| my own Webpack configs a few years ago, I've had
| approximately zero weird npm issues.
| christophilus wrote:
| I maintain a Rails codebase and a Node codebase. We are
| using esbuild for Node / JS bundling, along with
| TypeScript. The Node project is much less of a headache
| than the Rails one, mostly due to TypeScript. We've also
| made an effort to minimize our dependencies. We have fewer
| npm modules than gems.
|
| All that to say, Rails is fine. But Node is also fine, if
| you treat it more like Go (minimal dependencies, lean on
| the vanilla underpinnings).
| cutler wrote:
| Depends what you're comparing. Barebones Node with few
| dependencies is more like a Rack application. Rails is
| the other end of the spectrum.
| tqkxzugoaupvwqr wrote:
| > And let's hope that everything works and none of the 2000
| imported node_modules blow up when this tutorial is 3 months
| old.
|
| We have recurring Jira tickets for updating npm dependencies
| every two weeks. One developer is occupied between half a day
| and two days because the amount of breakage in the npm
| ecosystem is enormous. It's ridiculous and sucks the life out
| of us.
| ng12 wrote:
| In curious why you feel the need to do that? I typically only
| update dependencies either for serious security issues or new
| features I really, really want to use.
|
| I still have a few projects running Webpack 1 without issue.
| faizshah wrote:
| Large companies often have security mandates that
| dependencies should be regularly updated.
| madeofpalk wrote:
| I'm sure you have a lived experience that guides what you
| said, but this just hasnt been my experience.
|
| We just use dependabot to issue PRs for updating
| dependencies, and we merge automatically when tests pass.
| It's never caused an issue.
| faraaz98 wrote:
| I actually have dependabot enabled on a side project that
| I've stopped maintaining and every once in a while I get
| package update notifications.
|
| It works great but the underlying problem still remains I
| guess
| AprilArcus wrote:
| I sincerely do not understand this complaint. Do you dislike
| bug fixes and new features? Would you be happier with a
| stagnant tooling ecosystem?
| tqkxzugoaupvwqr wrote:
| Sadly it's the constant barrage of breaking changes. It's
| not just a version number bump and everything keeps
| running. Patch version breaks the app. Minor version breaks
| the app. Major version breaks the app (understandable in
| semver) but multiple inter-dependencies need to be updated
| in parallel.
| AprilArcus wrote:
| So part of my job is maintaining a complex webpack build
| system, and I do get that it's not a small amount of
| work. However, the changes I see aren't wonton. They're
| typically aimed toward a world that's more interoperable
| and more standards-compliant.
|
| For instance, Webpack 5 deprecated worker-loader in favor
| of a construction using new URL() and import.meta.url.
| Adopting this was a huge pain, but what we get in
| exchange is a system that can load workers using standard
| syntactic constructions that work under e.g. our test
| runner or in a NodeJS microservice. Something like that
| is worth the hassle to me.
|
| As for minor and patch versions causing breaking changes,
| this has happened to me a few times. Terser Webpack
| Plugin 3.0.6 exposed flaws in a custom Webpack plugin
| we'd written for internal use, which I cannot fairly
| blame on anybody but ourselves. Babel 7.5 broke CommonJS
| targets in a way that wasn't fixed until 7.6, which was
| truly unpleasant and something I hope to never deal with
| again. TypeScript doesn't use Semver and usually has
| breaking changes in every point release. For the most
| part, however, semver has proven trustworthy.
|
| The Darwinian foment that characterizes the front-end
| ecosystem has created the best tools I've ever used. When
| I look at the quality of tooling available on stacks that
| prioritize stability, I am not jealous.
| gboss wrote:
| Why not just use fixed versions and upgrade when you have a
| reason to?
| WJW wrote:
| That sounds like a nightmare waiting to happen. You have a
| package which hasn't been upgraded by your team for two
| years and suddenly someone finds a vulnerability in every
| version before 3.xyz.something. When you check, your
| version package is 1.3.5. Now you have to upgrade multiple
| major versions, and in all likelihood the package had
| transitive dependencies which have had many updates
| themselves as well. After several months/years of neglect,
| "upgrade when you have a reason to" has turned into a major
| undertaking and if you are especially unlucky it will take
| multiple devs many weeks to sort out the mess. All this
| time, your app will be running an unsafe version of the
| package and you can only hope that nobody finds out before
| the dependency upgrade is completed.
|
| Keeping your dependencies is boring and takes a lot of
| time, but the alternatives are far worse.
| yoyonamite wrote:
| Or just backport the fix
| ljm wrote:
| Another option is to ditch the dependency and roll your
| own, which for many things will be Good Enough(TM),
| especially as the JS standard library becomes more
| useful.
|
| Like, do you really need to import half of lodash or
| ramda just so you can one-line a few calls?
| AlchemistCamp wrote:
| I try to be judicious about adding dependencies, but
| Lodash is very well-understood and stable. It's actually
| the type I would add without any concerns whatsoever. I
| can't even remember hitting an issue due to it making a
| breaking change.
| stanislavb wrote:
| "Why not just"...
| k0t0n0 wrote:
| If you want things to be more stable use clojure
| AlchemistCamp wrote:
| I'm looking forward to Phoenix 1.6 which ditches Webpack for
| esbuild.
|
| So am I!
|
| I read Mitchell Hanberg's blog post on using it with 1.5 a
| while back: https://www.mitchellhanberg.com/how-i-handle-
| static-assets-i...
|
| I found it compelling but was concerned it was a bit early and
| not enough others would be using esbuild that issues I hit
| would be googleable. Now that it's the Phoenix default, that
| won't be a problem.
| masa331 wrote:
| It's still perfectly possible and valid to use Sprockets
| instead of webpack in a Rails app. That's what i do with every
| one of my applications and it works flawlesly
| ch4s3 wrote:
| When I used to use Rails pre-webpacker I felt like I was
| constantly fighting with sprockets. Trying to use it with
| assets from node modules isn't always straightforward, and
| it's pretty slow (or used to be).
| Madeindjs wrote:
| It works until you try using a library not available with
| Sprocket...
| sleepyhead wrote:
| How can it not be available with Sprockets? You can just
| add .js files.
| buf wrote:
| I started a saas company 2 weeks ago with the tool list
| described in the article. Already at $1k MRR.
|
| IMO, use whatever gets you to paid users fastest.
| edoceo wrote:
| Can you show it?
| airblade wrote:
| Rails will soon default to using ESM instead of Webpack.
|
| https://world.hey.com/dhh/modern-web-apps-without-javascript...
| e12e wrote:
| Oh, this is great news. I thought everyone involved with js
| (and coffescript) in rails were completely insane. Glad to
| see they were just doing the best they could in a crazy world
| (the early js world).
| gosukiwi wrote:
| Wow that sounds great. It looks like it's still quite new,
| but I love having webpacker as optional in Rails 7 and just
| using ESM instead, which seems much more sane.
|
| Still, there's the need to install NPM packages. You can use
| Skypack as a patch, but ideally you should be able to host
| all of your JavaScript. I guess you could use `npm` and
| manually link to those files in your configuration map, there
| could even be an automated Rake task to do it, but I don't
| know if that's the direction DHH has in mind.
| sergiotapia wrote:
| This is why Phoenix is ditching webpack! The story on the
| Elixir side is more compelling. I'm glad the team made this
| decision.
|
| https://sergiotapia.com/phoenix-160-liveview-esbuild-tailwin...
|
| Also medium sucks, please don't use it to write developer
| blogs. People can't read your article!
| scns wrote:
| Thank you very much for the blog post, it will save a lot of
| time and hair.
| sergiotapia wrote:
| It's something I wish I had handy a week ago. Hope it
| helps!
| mberning wrote:
| That has been the most disappointing thing to me with rails.
| The ruby part of it is so nice. The front end has always made
| me feel doubtful. It's not really the rails team fault that the
| frond end landscape is so tumultuous.
| fouc wrote:
| If rails is only used as an API, I found it much cleaner to
| have a separate codebase for the SPA and run webpack separately
| (or nowadays maybe use something like esbuild instead?).
|
| I was able to work with rails & webpacker precisely because I
| had experience with webpack separately, but webpacker had some
| weird limitations.
| stanislavb wrote:
| For the record, next Rails version (v7) is on the path of
| ditching webpack, too.
| appaone wrote:
| What? It was just integrated as default. Do you have a
| source/link for more information?
| norman784 wrote:
| It seems that swc is gaining more traction than esbuild, deno
| is using it, nextjs hired swc dev and rome is using swc too.
|
| Also one limitation by design of esbuild is lack of
| customization, you cannot hook into esbuild and do your own
| things, but I read you could with swc.
|
| But either way, both are way faster than the most popular ones.
| IggleSniggle wrote:
| It's very easy to hook into esbuild. The simplicity and ease
| of integration is a big part of what I like about esbuild. I
| haven't used swc, however, so I can't comment on how it
| compares.
| dstaley wrote:
| One thing that's important to keep in mind is that esbuild is
| a bundler, in that it can take an input file that imports
| other JS files and create an optimized ready-for-production
| output bundle file. SWC cannot, yet, accomplish this.[1] It
| is in the works, however! But if I was choosing a replacement
| for Webpack to use today, I'd definitely go with esbuild.
|
| [1] https://swc.rs/docs/spack-basic/#mode
| petepete wrote:
| I do kind of wish Rails had just taken the 'bring your own
| JavaScript and CSS' route instead of wrapping Webpack and adding
| a boatload of confusion due to multiple layers of things that
| don't feel like they were designed to work together.
|
| Tell me where to output my .js, .css and other assets and let me
| worry about compiling - or not as is often the case.
| baggy_trough wrote:
| Rails 7 is heading more that way.
|
| https://world.hey.com/dhh/modern-web-apps-without-javascript...
| [deleted]
| coffeefirst wrote:
| Django went that route and it's not great either.
|
| I think the ideal would be some kind of middle ground: an
| optional contrib module, plugin, or even just documented
| pattern that can serve as an officially supported approach
| without baking a strong opinion directly into the framework.
___________________________________________________________________
(page generated 2021-08-15 23:01 UTC)