rails / webpacker

Use Webpack to manage app-like JavaScript modules in Rails
MIT License
5.31k stars 1.47k forks source link

Any help doc about converting rails old assets pipeline to webpack? #803

Closed gamesover closed 7 years ago

gamesover commented 7 years ago

May I know is there any wiki doc about how to convert old assets pipeline to webpack? My rails is 4.2.6.

curvo commented 7 years ago

Hi @gamesover, I've been going through this process on the SCSS side thus far and am happy to help if you have any specific questions?

And otherwise, what are you looking for exactly? I'm considering at least writing up the approach we've used here at User Testing for this... but maybe there's more to share depending on the need. Thanks

gamesover commented 7 years ago

Hi @curvo , thanks for your reply. Our current js is structured by http://nandovieira.com/using-es2015-with-asset-pipeline-on-ruby-on-rails + a little vuejs. To be frank, we have a quite large and old rails project. To convert everything to SPA is a bit mission impossible. However, we want to use webpack to structure our js code to be easier to maintain and debug. If we cannot convert old code to vuejs, I hope we can write all new code in vuejs.

curvo commented 7 years ago

Hi @gamesover - we've got a ten year old project ourselves at User Testing. We are currently on Ruby 2.3.4 running Rails 4.2.9.

I just launched webpack to production on thursday but we decided just to compile a couple of main scss manifest files that were pulling in an internal design system toolkit which moved from being checked in to now dynamically being pulled in via yarn and then compiled by webpack.

There have been a couple of hiccups along the way, and a few of them popped up after launching. I have written some internal documentation that I would be happy to share with you personally via email but I am also pulling that stuff together for a blog post which then I can link to from here. I should be posting to our blog this week so I will link that here and hopefully it may help with potential issues you may face, especially with deployment.

On our side, I have not yet jumped into compiling js with webpack, but we have haml, es6, angular 1.4 (3 different approaches) and a bunch supporting js in our app. We do plan to move all of that over though, so, I'm sure to be tackling some of the same problems you face.

Off the bat, at least for CSS, I will say that we decided to put our packs in app/assets/packs. When we build with webpacker they go into public/development/assets/packs, public/staging/assets/packs or public/assets/packs for production. All of the pack use is for logged in states currently except for our login page itself (See: https://www.usertesting.com/users/sign_in).

We chose this structure mainly for it's simplicity within our current code base. At first I thought I needed a separate directory, but by staying within assets itself, we realized it would be less confusing to the entire team as it eliminates the general need to move so many things around. I'll elaborate more on that in our blog.

So for now, please email if you're like (bcase@usertesting.com) or as I mentioned, I will circle back here and post links to our blog posts when they are released (if that is allowed in this thread? @gauravtiwari ?).

gauravtiwari commented 7 years ago

@curvo Thanks for detailed example 🍰 Yes, please feel free to post as long as they are relevant ;)

Most of the things are same as asset pipeline (in terms of writing JS) except you will be using webpack to compile the JS code, which means you can write modern JS (thanks to babel). The only convention here is anything that you want to link in your view like say a calendar module on a calendar page, you would add that to app/javascript/packs folder - these are webpack entries. All source files can live under app/javascript though.

app/javascript: 
  src: # can be called src or anything of your choice
    #.. all files that are JS source, can be structured anyway you like
  packs: 
    # all webpack entry files, can be nested in sub-folders as well
    # this is where you can require source files and bootstrap them, like vue component render on DOMLoad etc.

I am going to close this one since this is not an issue.

gamesover commented 7 years ago

@curvo , thanks so much for your detailed reply. I am expecting to see your blog then :) Definitely, I can learn and apply to my current project. Thank you again.

curvo commented 7 years ago

@gauravtiwari I'm curious about the app/javascript convention. It feels like the wrong place to put sass/image files but maybe I'm just hanging onto older asset pipeline thinking? That's another reason why leaving all of the source files in the app/assets directories in our project seemed to make sense.

For new Rails 5+ projects is the idea that you might do something like this?

app/javascript:
    src:
        javascripts:
        stylesheets:
        images:
    packs:

It just bothers me a little bit having stylesheets and images under javascript, but like I said, maybe I'm holding onto old conventions? What patterns are people following?

For our Rails 4.2.9 project we are using this structure:

app/assets:
    fonts:                       # current font assets
    images:                    # current image assets
    javascripts:              # current js assets
    media:                      # current audio assets
    packs:                      # new packs entry point
    stylesheets:             # current scss/css files

I admit that shared_webpack_manifests isn't the greatest name but we needed a place to put snippets that are shared between packs but are essentially just sub-pack like files. (note: we've decided to simplify further and remove this directory)

One big advantage to this structure for our team is that we don't have to move our current assets from their app/assets/SUBDIRECTORIES to app/javascripts (or any place else). This conceptually seems to simplify the process of migrating files from sprockets to webpack.

Anyway, just wondering what you all are seeing/thinking around all of this? Thanks.

rossta commented 7 years ago

@curvo We're still in the process of migrating and made the explicit decision to leave stylesheets, images, and fonts in app/assets under Sprockets compilation. For us, it feels like it has simplified the process of getting to understand Webpack and focus on embracing new JS practices without worrying about how non-JS static assets get compiled. It also helps that these assets (for us anyhow) change less often.

For vendor dependencies, we're still able to remove the corresponding Rails asset gem and simply need to add the appropriate node_modules directory to the Sprockets load path:

# Gemfile
- gem "foundation-rails"

# package.json
"dependencies": {
   // ...
+ "foundation-sites": "~6.3.0",
   // ...

# config/initializers/assets.rb
+ Rails.application.config.assets.paths << Rails.root.join("node_modules", "foundation-sites", "scss")

Undecided on whether it's a permanent setup or not, but the ability to run Sprockets and Webpack side-by-side in development and run both pipeline during deployment made this an easy decision as a first step for us.

gauravtiwari commented 7 years ago

@curvo Theapp/javascript folder, which in reverse reads "javascript app" is basically meant for a modern JS app. Nowadays, people are writing CSS-in-Javascript and so many other things so as a convention the idea is here you can write your modern client app that can be completely written in Javascript (even styles if you like :)), obviously there will be other things in it like images but that's all makes the whole app and this is all possible because of Webpack, which can compile and bundle all these assets into one.

Totally, for projects that are migrating that setup makes most sense because you get best of both worlds and migrate the code without downtime, while learning new concepts. Most of the JS modules are now migrating to NPM so it's becoming easier than before to use libraries with Webpack.

Obviously, there is still some work to be done here to ensure the development experience is same as asset pipeline ;)

curvo commented 7 years ago

@gauravtiwari Makes sense... thanks for your response.

modkaffes commented 6 years ago

@curvo Has the aforementioned blog post been released maybe? 🙏

rossta commented 6 years ago

We just did a writeup of our experience integrating Webpacker into our Rails 4.2 app. Check it out and let me know what you think: https://rossta.net/blog/from-sprockets-to-webpack.html

7dir commented 6 years ago

@rossta where is git repo?

rossta commented 6 years ago

@7dir Company project, private repo.