Slide 1
Slide 1 text
How do framework and
buildtool handle webpack?
2019/03/23 Rails Developer Meetup 2019
@banyan / Kohei Hasegawa
Slide 2
Slide 2 text
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
Slide 3
Slide 3 text
Released new site this month!
Slide 4
Slide 4 text
No content
Slide 5
Slide 5 text
No content
Slide 6
Slide 6 text
Key takeaways
● Use webpacker if you don’t know webpack well.
Slide 7
Slide 7 text
Agenda
1. About Webpack
2. How do framework and buildtool handle webpack?
3. Diversity of Rails application
4. Can we improve webpacker?
5. Summary
Slide 8
Slide 8 text
What is webpack?
Slide 9
Slide 9 text
webpack is a module
bundler to build assets and
styles and scripts and
images.
Slide 10
Slide 10 text
No content
Slide 11
Slide 11 text
https://survivejs.com/webpack/what-is-webpack/
Slide 12
Slide 12 text
What is webpacker?
Slide 13
Slide 13 text
Webpacker is an abstraction layer
between Rails and webpack
Slide 14
Slide 14 text
Webpacker will be the
default in Rails 6
Slide 15
Slide 15 text
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
Slide 16
Slide 16 text
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?
Slide 17
Slide 17 text
Then, how do framework
and buildtool handle
webpack?
Slide 18
Slide 18 text
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.
Slide 19
Slide 19 text
webpacker
● Customizable
● Does not provide eject feature
Slide 20
Slide 20 text
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
Slide 21
Slide 21 text
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
Slide 22
Slide 22 text
No content
Slide 23
Slide 23 text
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
Slide 24
Slide 24 text
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.
Slide 25
Slide 25 text
The difference those how familiar with webpack
● The one who knows webpack very well
● The one who don’t know webpack at all
Slide 26
Slide 26 text
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...
Slide 27
Slide 27 text
https://dhh.dk/2012/rails-is-omakase.html
Slide 28
Slide 28 text
While the role of Rails is
expanding, the current
position of webpacker is not
that bad
Slide 29
Slide 29 text
Are you really in trouble
with webpacker?
本当に webpacker で困っていますか？
Slide 30
Slide 30 text
What I’m insisting is current situation is okay and I
have done nothing so far.
このままだとただの現状肯定おじさん
Slide 31
Slide 31 text
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
Slide 32
Slide 32 text
No content
Slide 33
Slide 33 text
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.
Slide 34
Slide 34 text
Sent PR and realised the problem.
● Difficult to be merged.
Slide 35
Slide 35 text
It looks like this method is able to generate...
Slide 36
Slide 36 text
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":{}}'
Slide 37
Slide 37 text
console.log(environment.toWebpackConfig())
Slide 38
Slide 38 text
No content
Slide 39
Slide 39 text
console.log(JSON.stringify(environment.toWebpackConfig()))
Slide 40
Slide 40 text
"plugins": [{
"keys": [
"Apple_PubSub_Socket_Render",
"CAML_LD_LIBRARY_PATH",
…
]
},
{
"options": {
"filename": "[name]-[contenthash:8].css",
"chunkFilename": "[name]-[contenthash:8].chunk.css"
}
},
{},
...
]
Slide 41
Slide 41 text
https://github.com/rails/webpacker/blob/b041a1/package/environments/base.js
Slide 42
Slide 42 text
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.
Slide 43
Slide 43 text
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.
Slide 44
Slide 44 text
Implemented as generator for now
● https://github.com/banyan/webpacker_ejector
● The target user is to eject minimally
Slide 45
Slide 45 text
Interestingly enough,
I’ve convinced one thing.
Slide 46
Slide 46 text
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.
Slide 47
Slide 47 text
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
Slide 48
Slide 48 text
Thank you!!