Yarn and Webpacker?

[michaelem]

Last week I did spend a while migrating some projects to Webpacker 3.0 and I have to say it's pretty much as simple to use as the asset pipeline now.
Should we move the project to those two?
This would also allow us to use modern javascript and babel for backwards compatibility.

[emcoding]

Can I start whispering "React" 😍 now?

[carpodaster]

👍 for keeping the asset pipeline clean

[michaelem]

@F3PiX trying to keep js as much confined to the frontend as possible here 😂

I think the biggest upside is that one can get rid of using gems that just wrap javascript code and just use npm packages instead. Of course the implication also is that people then have to learn to use yarn which might be a new hurdle (but a rather small one imho).

[emcoding]

I suppose going to yarn is not a big deal for Rails devs, because they are used to the gemfile.
(TBH I never used npm; now that I am learning React, I went straight to yarn.)
Can you add a short 'How to' to the wiki, with what is changing for this repo?

[carpodaster]

I thought webpacker was shipped with Rails v5.1 by default now? If that is so, this is definitely not too much to ask of a dev. And in any event, we need a line or two in our README anyway, so people should be able to just copy/paste it into the terminal.

[michaelem]

@carpodaster it ships but it is not the default. If you want to use it on a new project you run rails new --webpack.
But it ships with rails, integrates well and it might very well be default in the next release.

[michaelem]

@F3PiX if it's fine I'd write create a pull request and add fitting sections to the readme, I think the wiki is somewhat too detached for this kind of thing.

[emcoding]

@michaelem 👍 for the readme and the initial setup. I was thinking that the wiki is a nice place for a short notice on how to add new JS libraries. But no fuzz, just an idea.

[emcoding]

@michaelem @carpodaster I don't know if everyone but me uses Foreman to start the app? We can add webpack to Foreman, right? Saves the very hard and painful process 😂 of starting up two processes before you can start...

[michaelem]

@F3PiX with webpacker 3.0 webpack is anyway automatically started in the background if it's not running - so no need to start it manually unless you want live-reloading of javascript code: http://weblog.rubyonrails.org/2017/8/30/webpacker-3-0/

[emcoding]

COOL!!!! I didn't know that! (And that while it is almost 5 days old news!! 😉 )

[klappradla]

➕ on moving to "modern JS"™
Being familiar with these tools seems to be part of getting started with Rails anyways nowadays. So even given the slight plus on overhead for getting started with setting up the Teams App, I think it's a good thing to have 👍

[emcoding]

@michaelem Did you mean that you would like to take this on?

[michaelem]

@F3PiX yes, hopefully I'll get around to finish #846 today, then I can embark on this.

[emcoding]

@michaelem Is it correct that ES lint is a better choice for working with ES6 than JSlint?
Because we use currently JS lint.

[emcoding]

Edit: we are currently using jsHint. 🙈

[carpodaster]

Hey @michaelem – just wanted to ping you if you were able to advance this. Anything one can help you with?

[michaelem]

Hey, as signified by my response time I did not really manage to carve out time for this, although I think I can actually give it another try next week, since that should be a bit more quiet.

[klappradla]

Only 65% related to this ticket but I didn't want to open up a new one 🙈

Looking at this PR 👉 #877, seeing how changing a single line in a view template fully decouples its necessary Javascript functionality made me question if we should do something about the general structure of JS in the app as well. Right now it's just randomly placed, named and formatted files - all untested which makes it hard for people new to the project to see whether a page requires certain JS code and also where to put new code.

I was thinking we could at least go for "page / controller specific JS" which has been sort of a pattern in Rails if an app did not use client-side frameworks.
(some examples of this can e.g. be found in organizing-javascript-in-rails-application-with-turbolinks, how-to-do-structure-javascript-and-css-in-ruby-on-rails or using-es6-with-asset-pipeline-on-ruby-on-rails)

Does anyone of you know of any other common patterns for this?

[emcoding]

@klappradla I stumbled upon this: https://evilmartians.com/chronicles/evil-front-part-1
I like the general idea, although it's propably one step to much for us...

[klappradla]

Yes, fully agree @F3PiX ✌️ I know this tutorial and I also really like what they're doing. But as you wrote, especially putting the HTML files into what is normally called app/javascript in a default Webpacker setup is one step too far for us 😉

Having a app/javascript, a app/services directory etc. is fine and pretty much standard for a modern Rails 5+ application. But introducing this rather opinionated component approach will probably make our app a bit less approachable for newcomers and new contributers. So I'd for now not jump on that train yet 🚂

What I plan to have is:

• webpacker for JS and CSS
  • also: being able to install frontend things with yarn add and keep them up 2 date 🎉
• use ES6 for JS and BEM for CSS / SASS
• have linting for CSS and JS
• have "controller-specific" JS code (pretty much a Rails best practice now I would say)