Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
そろそろWebpackと真剣に向き合ってみる
Search
Sponsored
·
Ship Features Fearlessly
Turn features on and off without deploys. Used by thousands of Ruby developers.
→
nao-bt
May 04, 2017
Programming
5.2k
9
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
そろそろWebpackと真剣に向き合ってみる
We Are JavaScripters! @6th【初心者登壇歓迎!LT大会】で使用した資料です。
https://wajs.connpass.com/event/54667/
nao-bt
May 04, 2017
More Decks by nao-bt
See All by nao-bt
僕のフロントエンド奮闘記コンポーネントで、すったもんだ
naotobt
1
1.1k
Other Decks in Programming
See All in Programming
Claude Opus 4.6以後の受託開発エンジニアの変化(Claude Code開発ノウハウ大公開スペシャルbyクラスメソッド)
iidatakuma
1
910
React本体のコードリーディング
high_g_engineer
0
120
霧の中の代数的エフェクト
funnyycat
1
450
地域 SRE コミュニティ最前線 - ホンマでっかSRE勉強会
tk3fftk
0
290
信頼性について考えてみる(SRE NEXT 2026 miniLT)
hayama17
0
230
壊れたパーサから始める関数型設計と構成的なパーサ #fp_matsuri
raiga0310
2
420
生成AI導入の「期待外れ」を乗り越える ー 開発フロー改革が目指す、真の組織変革
starfish719
0
2.8k
ソフトウェア設計に溶けるインフラ ― AWS CDK のインフラ認識論
konokenj
3
710
JAWS-UG横浜 #102 AWSサ終供養LT会 成仏できない AWS サービスたち 〜本日、三体供養します〜
maroon1st
0
280
SREの積み重ねがAI駆動開発のガードレールになった ― 7つの実践/SRE Guardrails The 7
tomoyakitaura
9
5.8k
Laravelで学ぶ Webアプリケーションチューニング入門/web_application_tuning_101
hanhan1978
4
1.5k
ITヒヤリハットを整理してみた ~ライフサイクルと原因から考える再発防止策~
koukimiura
1
120
Featured
See All Featured
New Earth Scene 8
popppiees
3
2.4k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
27k
Fashionably flexible responsive web design (full day workshop)
malarkey
408
67k
Google's AI Overviews - The New Search
badams
0
1.1k
It's Worth the Effort
3n
188
29k
The Curious Case for Waylosing
cassininazir
1
440
How to audit for AI Accessibility on your Front & Back End
davetheseo
0
480
GraphQLの誤解/rethinking-graphql
sonatard
75
12k
Pawsitive SEO: Lessons from My Dog (and Many Mistakes) on Thriving as a Consultant in the Age of AI
davidcarrasco
0
200
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
254
22k
KATA
mclloyd
PRO
35
15k
Embracing the Ebb and Flow
colly
88
5.1k
Transcript
そろそろWebpackと 真剣に向き合ってみる。 NAO-BT
自己紹介 文系出身・プログラミング歴は約4年目 サーバーもフロントもやる人になってきてる。 ※できるとは言っていない。日々勉強中
JSに関しては 4年前 前の会社の研修でちょこっといじる。 約1年前 Angularの1.4系を前の会社の業務で利用。 徐々にJSの面白みを感じ、個人的にフレームワークを中心に 勉強をはじめる(Angular2,React) 現在 サーバーサイドはPHP(フレームワークはLaravel)、 フロントはVue.jsで業務システムのSPAを作っている。
JSのフレームワークで 毎回躓くところ。
ビルドまわりがよくわからん。
なんで必要なのかわかってないから フレームワークのチュートリアルをやるとき、 大体躓く。 グッタリ _(:3 」∠)_
でも最近、 おぜん立てしてもらえるので なんとかなる。 Vue-cli create-react-app Laravel-mix
なんとかなってしまった結果・・・ なんとなくわかった気になる。
いやいや!! 便利ツールによりかかってるだけで、 理解してないよね!? サポートおわったらどうすんの!?
ということで、 JSの知識が少しは身についた今、 もう一度 ビルドまわりと向き合ってみる。
とりあえず、 Webpackと向き合ってみる
Webpackは各CLIで使われている create-react-appのreact-script Vue-cli
そもそもなんで、WebPackを使うの?
★★★ Webアプリを効率よく開発するために 分割したモジュールの 名前解決・依存関係を整理してくれる。 ★ TypeScriptやJSXをトランスパイルする。
JSの役割がWebサイトの 簡単な装飾程度なら、 そんな必要はなかった。 1ファイルにまとめられる程度の量に収まる。
しかし、 非同期通信やDOM操作など 様々な機能をページに盛り込む SPAなサイトを作ろうとすると 大量のJSを書くことになる。 これを一つのファイルに 書き続けることは、かなりしんどい。
大量のJSのコードを モジュールごとにわける サブルーチンやデータ構造を役割ごとに分割したものをモジュールと言います。 モジュール同士の依存性を可能な限り減らし、 保守性を高めて再利用可能にすれば、開発もはかどる!
フレームワーク利用の利点には DOM操作や非同期通信を簡単に書ける! というのもありますが・・・、 それぞれの思想に沿って使えば 最適なモジュール構成になります。 ・MVVM ・コンポーネント指向
そもそも、Javascriptは 「Webのページにちょっと動きを与える言語」 という想定だったので、 言語仕様としてモジュールをサポートしていません。 ビルドツールを使わなければ モジュールパターンというコーディングのテクニックを 使っているにすぎない。 ただし・・・
そのまま、開発しようとすると <head>タグがこんなことに・・・。
JSの悩ましいモジュールの実情 グローバルオブジェクト内の競合や 読み込む順番を間違えると、エラーが起きるので どんなモジュールがあるか開発者は把握していないといけない。 システムが大きくなればなるほど、 <head>タグ内の<script>リストが長くなる。
それを ビルドを通して解決する JS JS JS JS JS JS JS
ビルドとは 複数のソースコードを基に 組み合わせて 実行ファイルを生成する作業。 この中でモジュール間の 名前解決、依存関係の解決を行っている。
Webpackは まずはこれさえ、 分かれば怖くない。 Entry Output Loaders Plugins
Entry コンテキストルートとなるファイルの指定。 そのファイルから依存関係を追跡するようにwebpackに指示します。 Webpack.config.js entry.js module1.js
Output ビルド結果の出力に関する指定。 filenameはビルド後に出力されるファイル名、pathはそのファイルの出力先 Webpack.config.js Index.html
Loaders ビルドの際にモジュールのソースコードに適用される変換を指定します。 これの利用でJS以外の拡張子(jsx/vue/ts/css/img) のものもビルドできるようになります。 package.json 拡張子がcssのファイルをjsに 変換するためLoderを npm install する
拡張子がcssのファイルにインストールした Loaderを使うよう指定 Webpack.config.js
Loaders entry.js modulecss.css Index.html
Loadersではまったところ testってしないとビルドが通らない! Webpack.config.js package.jsonのscriptsみたいに自由に書き換えられるのかと思いきや・・・
Plugins ビルド時の設定を行います。 ビルドする際にファイルの圧縮をおこなったり(UglifyJsPlugin)、 コンパイルエラーが起きてもスキップする設定ができる(NoErrorsPlugin)。
Webpack 2になって変わったこと① Webpackはver2からES2015でjavascriptの新しい言語仕様に採用された import・exportが使えます。 このほかのES2015の仕様を利用したい場合は、LodersでBabelを使用する必要があります。 entry.js module1.js
Webpack 2になって変わったこと② TreeShakingという機能が加わり、 exportしているけどimportされていない モジュールはプロダクションビルドの際に 含まれなくなった。
まだまだ勉強が必要・・・ 「インストールしたフレームワークなどのライブラリーと 開発で作ったアプリケーションのコードはビルドの際には分けておいたほうがいい。」 と言われて、laravel-mix上ではできたんですが、素のwebpackではできなかった・・・。 他にも効率の良いビルドの設定の追求を目指し、お助けツールに頼ってばかりにならないよう チュートリアルを読み込みながら頑張りたい・・・
つたない発表ですみません。 ご清聴ありがとうございました。