How do framework and buildtool handle webpack?

Transcript

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!
6. Key takeaways • Use webpacker if you don’t know webpack well.
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.
11. https://survivejs.com/webpack/what-is-webpack/
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 https://github.com/timarney/react-app-rewired 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 https://github.com/survivejs/webpack-merge • 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. ▪ https://github.com/vuejs/vue-cli/issues/2796
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
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...
27. https://dhh.dk/2012/rails-is-omakase.html
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: https://github.com/rails/webpacker/pull/1916
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 merged.
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())
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" } }, {}, ... ]
41. https://github.com/rails/webpacker/blob/b041a1/package/environments/base.js
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 • https://github.com/banyan/webpacker_ejector • 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!!