How do framework and buildtool handle webpack?

D9511b3f1579c63dcfa680a8c945592b?s=47 Kohei Hasegawa
March 23, 2019

How do framework and buildtool handle webpack?


Kohei Hasegawa

March 23, 2019


  1. How do framework and buildtool handle webpack? 2019/03/23 Rails Developer

    Meetup 2019 @banyan / Kohei Hasegawa
  2. About me • @banyan / Kohei Hasegawa • Work at

    Quipper since 2013. • Mainly working on frontend (React, TypeScript, PWA) and haven’t written Rails much these days :P
  3. Released new site this month!

  4. None
  5. None
  6. Key takeaways • Use webpacker if you don’t know webpack

  7. Agenda 1. About Webpack 2. How do framework and buildtool

    handle webpack? 3. Diversity of Rails application 4. Can we improve webpacker? 5. Summary
  8. What is webpack?

  9. webpack is a module bundler to build assets and styles

    and scripts and images.
  10. None

  12. What is webpacker?

  13. Webpacker is an abstraction layer between Rails and webpack

  14. Webpacker will be the default in Rails 6

  15. What does webpacker do? • webpack can be used immediately

    after rails new. • Provide javascript_pack_tag helper and others to link JavaScript assets • Quick start of React, Vue, Angular, Elm and Stimulus and others
  16. There are also criticisms towards webpacker • The config api

    is extra cost to learn if one knows webpack very well. • Update to webpack 4 is slow. ◦ It has finally been released recently though. • Better to discard webpacker when rails app is initialized. ◦ Is this only in Japan context?
  17. Then, how do framework and buildtool handle webpack?

  18. create-react-app • A build tool to create React application •

    Basically, not customizable • Provide eject feature • Some tools such as enables us to overwrite config. It’s community based.
  19. webpacker • Customizable • Does not provide eject feature

  20. vue cli 3 • A build tool to create Vue.js

    application • Customizable ◦ Using • Does not provide eject feature ◦ More importantly, we want to encourage people to stay away from ejecting so that they get upgrade capabilities in the future. This is important from both a bug fix and security perspective. ▪
  21. Phoenix 1.4 • An application framework for Elixir • Changed

    build tool from Brunch to webpack • Eject as default ◦ webpack config files would be copied after initialization
  22. None
  23. So what’s the best way to handle webpack? • There

    is no best way neither framework nor build tool ◦ Everything is trade-off • It depends on how much user knows webpack and also the type of applications
  24. The role of Rails has been changed • Rails takes

    care everything from view to API from 10 years ago. • There is a case that rails is used only for API nowadays, the major frontend battlefield has been moved away from Rails. ◦ For frontend, SPA is getting more popular.
  25. The difference those how familiar with webpack • The one

    who knows webpack very well • The one who don’t know webpack at all
  26. The difference between the type of the application • Rails

    handles all, from view to api • SPA on rails • Separate SPA and use Rails as api server • Back-office purpose • etc...

  28. While the role of Rails is expanding, the current position

    of webpacker is not that bad
  29. Are you really in trouble with webpacker? 本当に webpacker で困っていますか?

  30. What I’m insisting is current situation is okay and I

    have done nothing so far. このままだとただの現状肯定おじさん
  31. However, can we improve webpacker a bit better? • What

    if webpacker has eject feature? ◦ As an escape route when webpack config can’t be easily configured if webpacker has hard code. ◦ For those who are familiar with webpack don’t need webpacker layer. ◦ We can start with webpacker until we reach the problems. • Alright, I think I can easily add eject feature... ◦ Tried:
  32. None
  33. What do we need to do for ejecting? • Generate

    webpack config ◦ Take over the settings of loader ▪ e.g. Using babel-loader • Prepare helper methods ◦ Extracting view helper is additional step. So use webpacker’s one for now.
  34. Sent PR and realised the problem. • Difficult to be

  35. It looks like this method is able to generate...

  36. When the class is evaluated using JSON.stringify, the result is

    empty. $ node > class Foo {} undefined > JSON.stringify({ a: 1 }) '{"a":1}' > JSON.stringify({ a: new Foo() }) '{"a":{}}'
  37. console.log(environment.toWebpackConfig())

  38. None
  39. console.log(JSON.stringify(environment.toWebpackConfig()))

  40. "plugins": [{ "keys": [ "Apple_PubSub_Socket_Render", "CAML_LD_LIBRARY_PATH", … ] }, {

    "options": { "filename": "[name]-[contenthash:8].css", "chunkFilename": "[name]-[contenthash:8].chunk.css" } }, {}, ... ]

  42. The reason why webpacker:eject is difficult to implement. • Generate

    config dynamically is difficult with the current implementation of webpacker. ◦ Parse source code seems over engineered. ◦ Double maintenance for templates of eject codes and webpacker’s codes. ◦ This problems is how to compose object. • So I had to take approach to write template and read the current settings of rails application. Then generate config.
  43. Ideas to improve • There might be advantages if we

    use webpack-merge to compose webpack config. ◦ The code of webpacker itself can be readable. ◦ Learning-cost might be less since webpack-merge is used in the frontend community ◦ Eject can be easily implemented since it just needs to be copied. • If we change API, it will require migration too. • Another problem is I don’t have enough passion to do that.
  44. Implemented as generator for now • • The target

    user is to eject minimally
  45. Interestingly enough, I’ve convinced one thing.

  46. After created, I realised I won’t use. • There are

    many changes in architecture like serverless and microservice. • As I already work with SPA since 2013 and use rails just as api server. • I don’t see the future that I use Rails which handles everything inside as 10 years ago ◦ as I did to turn off turbolinks when turbolinks was just released.
  47. Summary • No best way on how frameworks and buildtools

    should handle webpack. • While the role of Rails is expanding, the current position of webpacker is not that bad. • Unless you really need to do, you don’t need to discard webpacker
  48. Thank you!!