got a high level overview? about webpacker

[dhh]

Ryan, great to have your help! I'll flesh out the high-level overview soon, but the key points are as follows: 1) We focus on using Webpack to manage app-like JavaScript, leaving CSS/images to the asset pipeline for now. 2) Webpack and asset pipeline coexists in the same projects. Each use their own helper tags and we'll have a way for sharing digests to reference production paths. 3) Right now we're using using --watch, not the dev server. 4) Production deploys will compile via both asset pipeline and webpack as needed. Do explore this against rails/master and come back with PRs :)

…

On Fri, Dec 9, 2016 at 10:34 AM, Ryan Mohr ***@***.***> wrote: Hey all, great to see rails finally coming around to the idea of built-in support for a modern js stack. Last year I converted a 60k sprockets/coffeescript/backbone project <https://kumu.io> over to webpack/babel/react and learned a lot about how to get these two systems playing nicely with each other in the process, without pulling your hair out in the transition process. Happy to offer whatever advice I can on the lessons I learned doing so and help out with the implementation too. Is there a high-level overview anywhere that describes the general architecture you're shooting for with this? - What will the interop between sprockets/webpack look like? Will it be one way or both? - Do you plan to support webpack's dev server or push everything through sprockets instead? (we've been more than happy / productive letting sprockets run the show -- we use storybook <https://getstorybook.io/> for rapid component development instead) IMO, one of the biggest value-adds you can create with this is an opinionated stance on babel/wepack plugin presets and path resolution. That's where most of the friction is getting started (and where most of the gains are for keeping large javascript apps well organized). eslint-loader + es2015/react/stage-0 + coffee-loader/add-module-exports (required for seamless commonjs interop) + style-loader/postcss is a great combo. Also, I wouldn't write-off webpack's css and image support just yet. They can live happily together alongside sprockets and there's good reason to support both (inlining tiny images and allowing react components to directly require the css files they need -- keeping the two next to each other makes things far easier to develop/maintain). There's lots of good work being done on the inline-style front but FWIW I haven't found anything I'm comfortable with using in production. Selector-based styles still get the job done just fine and ease the transition process from sprockets to webpack. Just wanted to throw this out there in case it helps. Can't wait to see it land! I think rails api + actioncable + built-in webpack/babel support is going to be huge. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#11>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAKtTJq0Pno7FKYavbqi4d4IbendlS4ks5rGZ9CgaJpZM4LJOpU> .

[rymohr]

Awesome. Let me throw some notes together for you to review first, then I'll take a stab at the PRs.

[rymohr]

Here's my first stab at the notes for anyone interested in chiming in: https://kumu.io/rymohr/webpacker

We've been using this system for a year now and super happy with it. Juggling over 100k lines of js now, and expanding it soon to support multiple products across the same codebase too.