はじめに 今回はwebpackやBabelについて学習したことを理解を深めるために文章としてアウトプットしていこうと思う。 そもそもなぜwebpackやBabelに関して学習しようと思ったかは、これまでTypeScript、React等を用いて様々なアプリケーションを開発してきたが、webpackやbabelに関する知識が曖昧なまま開発ばかりを行なっていた。なんとなく"とりあえず変換してくれているもの"程度の知識しかなかったので、しっかり理解していこうと思う。 そんな中でwebpackやbabelの必要性を学習していくうちにJavaScriptの歴史を理解した方がわかりやすいと思ったため、JavaScriptの歴史についても触れていこうと思う。 JavaScriptの歴史 JavaScriptの誕生 JavaScriptの1995年にNetscapeの技術者であるブレンダン・アイクが開発し
前置き HTMLを納品する形式の仕事の際にEJSやpugではなくReact+TypeScriptを使ってHTMLを生成しつつ開発体験を高めてほしい。 ということで具体的にどのようなメリットがあるのかを伝えたくてまとめてみました。 開発環境 1から環境を作るのは大変なので今回はクラクさんのministaを拡張していきます。 ministaの紹介記事はこちら 必要な設定はTypeScript, ESLint, Prettier, Babel, エディター(今回はVSCode)になります。 webpack.config.js const path = require('path') const glob = require('glob') const HtmlWebpackPlugin = require('html-webpack-plugin') const webpackConfig =
TikTokの開発元で知られるByteDanceのWebインフラチームは、Rust製の高速なwebpack互換バンドラ「Rspack」（発音はɑrespæk、アールエスパックもしくはアールエスペックのように聞こえます）をオープンソースで公開しました。 アイコンは雷光のように素早いカニで、コンパイルの高速性を表しているとのことです。 Hello world! We are from ByteDance. https://t.co/8d7t2qga7o — Rspack (@rspack_dev) March 10, 2023 バンドラとは、複数のJavaScriptやTypeScriptの依存関係などを解決し、コードやフォント、画像などのリソースなどをまとめるバンドルツール（あるいはモジュールバンドラやビルドツールなどとも呼ばれます）です。 多数のライブラリやコンポーネントなどを用いてチーム
JSConf JP 2021 の基調講演として発表したスライドです。 https://jsconf.jp/2021/talk/javascript-maintaining-ecosystem-oss-struggles-and-challenges
Module Federation(以下 mfe)は webpack@5 から入る新しい仕組みの一つです。 Proposal Merge Proposal: Module federation and code sharing between bundles. Many builds act as one · Issue #10352 · webpack/webpack This is a proposal to merge my existing work into the Webpack core. The base concept is federated ap... 目的 アプリケーションを作る時に、webpack はビルド時のソースコードは使う前提で実行するので、様々な最適化を行うことができます。 もし、node_modules 経由以外でライブラリを使うという場合は scrip
webpack/lib/config/defaults.js 実際に使うときの設定 結論ですが、webpack.config.js へ以下のように書くことが推奨されます。 module.exports = { cache: { type: "filesystem", buildDependencies: { config: [__filename], }, }, }; あとは、各コードの設定に依存するためversion等の追加が必要になる可能性があります。 ドキュメント Other Options | webpack webpack is a module bundler. Its main purpose is to bundle JavaScript files for usage in a browser, ... 仕組み ファイルキャッシュでは以下のようにデフォルトではnode_m
モダンフロントエンド = 宣言的 UI = 仮想 DOM ターゲット npm ツールチェインが使えない環境で、パフォーマンスを悪化させずにモダンフロントエンドをやりたい人 サードパーティスクリプトを提供する人 方向性 省ビルドサイズを目指す とくに外部から読み込まれる 3rd party script は、サイズ要求が厳しい lighthouse で 100 点の環境の点数を落とさないためには、おそらく 3rd は 20~30kb 未満を目指す必要がある 今後パフォーマンスが SEO に関わってくるので、このへんは重要 Google、ウェブサイトの UX 健全性を示す Web Vitals を導入。3 つの重要指標は LCP/FID/CLS | 海外 SEO 情報ブログ 実行時パフォーマンス要求 よほど複雑なアルゴリズムを実行するので無い限り、省ビルドサイズ制限を満たせば十分 モバイルで重
Rails7がもつフロントエンドへの「答え」
Rails7のアルファ版がリリースされました。 最近、Railsニューリリースの記事をみてもテンションがあがらなかったのですが（個人開発ではもっぱらNext.jsとかFlutterのお世話になってました）、下記のDHHによるデモが久々に 「Railsっていいかも」 って思える内容だったので、背景も含めて解説します。 Railsの存在意義 みなさんは、どうやってRails使い始めましたか？ 自分はRails3.1あたりで独学でウェブアプリ開発をはじめました。そのときに「簡単に始められて」「ビジネスロジックが増えても生産性が落ちない」 というあたりで、他に浮気する理由がなかった、というのが私の理由です。 それから数年が経ちますが、最近のRailsのアップデートは Basecamp(Railsの基となった製品)が必要としている機能がポートされているだけ という印象でした。 アプリケーションの複雑
こんにちは、メルカリでフロントエンドエンジニアをしている @karszawa です。 本日はメルカリアドベントカレンダー2019の21日目の記事として「メルカリアプリのWebView向けWebアプリケーションの開発を支えるモック技術」というニッチ（？）な題目の話をさせていただきます。 メルカリアプリでは「取引画面」を代表として、意外と多くの場所で WebView が使われています。 WebView 向けの Web アプリケーション開発は動作環境が特殊で外部依存の多いという点で普通の Web アプリケーション開発よりややこしいです。たとえば、普通の Web アプリケーションはあるアプリが独自に定義した API（ネイティブ API）を呼ぶことはありません。この記事ではそういった難しさを持ったアプリケーションを開発する上で重要な モックの話 をします。 本番環境と開発環境のアプリケーションが参照
こんにちは、エンジニアの@dachi_023です。最近、MacBook Proの調子が悪いのですが修理に行くのが面倒で行っていません。放置し続けていたら直ったりしないかな・・・。 今回の記事はGatsbyで100ページ超えの静的サイトを構築したときの学びについてです。Gatsbyって実際どうなん？って思っている方に読んでもらえたら幸いです。 つくったもの ママリユーザーが本当に使ってよかったと思う商品・サービスの口コミを元に、自分と家族に合うものを探すことができる「ママリ口コミ大賞」の2019年 秋版のサイトをGatsbyで実装しました。妊娠中の方、育児中の方におすすめしたいサイトです。私も実際つかってみて、「これ、子どもが産まれた時にあったらもっと便利だったな〜！」って毎回思っています。 award.mamari.jp これまでの技術選定 ママリ口コミ大賞は今回で3回目なのですが、毎回使
はじめに ねぇまってむり webpackでこれ以上消耗するの つらいょ というみなさんへ これを期に 理解しましょう webpack 今回の記事は webpack の公式ドキュメントhttps://webpack.js.org/ (CC BY 4.0) から内容をたくさん引用しています。ありがとう Webpack チーム! 本題に入る前に 何故webpackを使うのかを考えてみましょう こういうのは何故必要かも理解しておくと有り難みが増すんやで。 はるか昔の javascript 有史以前、ブラウザでJavaScriptを実行する方法は2つありました まず１つ目としてスクリプトタグで各機能ごとに切り分けたファイルを読み込む方法があります。しかし大量のスクリプトをロードするとネットワークのボトルネックが発生する可能性があるため、この方法ではスケーリングが困難であると考えられました。 2番目の
AWS CodeBuildでのRailsアプリのdocker buildを早くしたい - クックパッド開発者ブログ
メディアプロダクト開発部の後藤(id:mtgto)です。 世間ではバレンタインですね。最近私はハンドメイドスイーツオークションというWebサービスの立ち上げをやっていました。ライブ配信でバレンタインのスイーツを作っていただき、ライバーのファンがスイーツをオークション形式で実際に購入できるというサービスです。 私のチームでは仮想DOMを扱うのにVue 2を使うことが多いのですが、今回は期日がずらせないイベントだったことや必要なライブラリがReact版しか提供されていなかったこともあり私がVueより使い慣れているReactで作りました。 本記事ではAWS CodeBuildでのRailsアプリのDocker buildを早くするための工夫を紹介します。 docker buildを早くしたい理由 クックパッドでは多くのアプリケーションを運用していますが、その多くはAWS ECS上で動いています(
実践 Node.js Native ESM — Wantedlyでのアプリケーション移行事例 | Wantedly Engineer Blog
Wantedlyではこのたび、フロントエンドアプリケーションのひとつをNative ESM化しました。本記事ではNative ESM化の必要性と、必要な作業について説明します。 この記事の概要Node.jsにはNative ESMというモードがある。Native ESMはまだ普及していないが、ライブラリ側の更新が進み、移行が必要になりつつある。Native ESMをめぐる状況は (この記事の長さからわかるように) 色々複雑で、概念をちゃんと説明するだけでも大変。Native ESMへの移行にあたってはさまざまな困難が待ち受けている。Native ESMとは歴史的経緯から、JavaScriptには複数のモジュールシステムがあります。そのうちNode.js周辺でよく使われるのはCommonJS ModulesとES Modulesです。 CommonJS Modules (CJS) は実質的に
JavaScript や TypeScript を使ってウェブアプリを提供する場合、開発時はimportやexportなどの ES Modules を使い、公開時はファイルをバンドルして公開することが多い。 以下の記事に書いたように、現在の主要なブラウザは ES Modules に対応してものの、バンドルせずに公開してしまうとパフォーマンスに悪影響を与える可能性がある。 numb86-tech.hatenablog.com ファイル数が増えれば増えるほど影響は深刻になるため、依存関係が深いライブラリを使っている場合などは、レイテンシが飛躍的に増加してしまう。 そのため、バンドルせずに公開するのは現実的ではない。 バンドルしてひとつのファイルにまとめてしまえば、JavaScript のダウンロードは一度で済む。 しかしそうすると今度は、バンドルファイルの肥大化という問題が発生する。 巨大なフ
この機能が導入されることにより、{raw/file/url}-loader が不要となります。 webpack@4 でも使えますが、まだ実験的フェーズです。 Documentation Asset Modules | webpack webpack is a module bundler. Its main purpose is to bundle JavaScript files for usage in a browser, ... モジュールタイプと以前との対応表 asset/resource -> file-loader asset/inline -> url-loader asset/source -> raw-loader asset -> asset/resourceとasset/inlineを自動選択する(閾値: 8kb) 使い方 実験フラグをオンにする。 // webpa
今あえてTypeScriptのビルド＆バンドルツールを探してみる | フューチャー技術ブログ
ちょっとしたフロントエンドの開発で、TypeScriptに最初から対応していて、簡単に使えるものは何かないかな、と調べてみたメモです。React/Vue/Angularの場合はそれぞれの初期化コマンドで何から何まで用意してくれます。Next.js、Nuxt.js、Gatsbyなども、これらのビルドのステップを簡略化するコマンドを提供しています。基本的にこれらのウェブフロントエンドを開発するときには、小規模・中規模ぐらいならあんまり気にしなくておまかせでもいいと思います。 今回は、それらのフレームワーク固有のビルドツールとは別に環境を作りたい人で、TypeScriptの環境が欲しい、ウェブの開発がしたい、という前提でいろいろ探してみました。 今回試してみたのは次の4つです。 Parcel Fusebox ncc Rome.js JavaScriptのビルドツールとはJavaScriptでビル
GitHub - evanw/esbuild: An extremely fast bundler for the web
A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch?
まず前提として、webpack.config.jsそのものをTypeScriptで書くことができる。公式ドキュメントにも記載があり、ts化自体は数分で終わる。しかし、このwebpack.config.jsをStoryBookの設定から参照するなど他のツールから読まれるときにTypeScriptだと不都合な場合がある。そのようなときに、この方法を使うと1分もかからず補完の効く環境を用意できる。便利なので是非導入してほしい。 Configuration Languages | webpack How 方法は簡単で、@types/webpackをインストールし、上の動画のようにコメントを書くだけ。
Node.jsのNative ESM対応は夢の機能ですが、夢を詰め込みすぎたせいかCJSからの移行を難しくしているポイントが依然として存在します。そのひとつが拡張子問題で、Node.jsのNative ESMではモジュールの拡張子を明示しなければいけなくなりました。 (これはWebブラウザの挙動に近づけるための判断だと考えられます。) 特にTypeScriptと他のツール (JestやWebpack) と組み合わせて利用している状態でのNative ESM化は実質的に未解決の状態だと言えます。本稿ではこの現状についてできる範囲で状況説明を試みます。 Node.jsの拡張子の扱い Node.jsはCJSとESMの2つのモジュールフォーマットをサポートしていますが、これらは単にパーサーが異なるだけではなく、実質的には「2種類の異なるモジュールシステムがFFIで繋がっている」程度には隔たりがあり
複数のモジュール形式(CommonJS, ES Modules, UMD)をサポートしたnpmパッケージの作り方 in TypeScript - dackdive's blog
はじめに npmパッケージを開発するとき、パッケージ利用者の実行環境に合わせて適切なモジュール形式のファイルをパッケージに含め、提供する必要があります。 具体的には、たとえば以下のようなバリエーションが考えられます。 Node.js環境であれば CommonJS 形式 (module.exports / require() ) ブラウザ環境で、webpackやRollupなどのモジュールバンドラーを前提とするならば CommonJS や ES Modules 形式 (export / import ) ブラウザ環境で、モジュールバンドラーなどは使わず<script>タグでファイルを読み込んで利用するならば UMD 形式 このとき、パッケージ提供側はどういったファイルをパッケージに含めるべきなのか、またそれを TypeScript でどのように実現できるのかがあまりよくわかっていなかったので
css-loader と style-loaderを間違えない ~css-loaderを使わずにcssを使ってみる~
css-loader と style-loaderを間違えない ~css-loaderを使わずにcssを使ってみる~2020-06-26 css-loader と style-loader どっちがどっちかってたまになるので、そうならないための備忘です。 これらは webpack の loader であり、JS で構築されるアプリケーション内で CSS を扱うために利用されます。 最近は CSS in JS の利用も増え、CSS ファイルを読み込む機会は減ってはきているものの、reset.css を読み込んだり、UI ライブラリが提供するグローバルな CSS を読み込んだりと CSS を直接 JS に import する機会はまだまだ多いと思います。 そして 1 ファイルでも CSS を読み込むなら loader にその設定が必要となるので、まだまだお世話になり続けるでしょう。 そんな利用
今年から ZOZO テクノロジーズの Web エンジニアになりました。@takewell です。 もう年の瀬になりました。一年は早いですがブラウザの寿命は存外長いです。 来年はきっと Internet Explorer のサポートブラウザから外すことができるかもしれない。来年はわざわざツールを介さずとも ECMAScript 202X が動くブラウザが世界中のみなさんに使われるようになるかもしれない。そう願ってなりませんが、現実はそうではありません。 こうした課題を少しでもマシにするために webpack (シェア 76%)を代表とする ESNext (ECMAScript Next Generation) なコードをレガシーブラウザにビルドしたり、コードを単一ファイルにバンドルしたりするツールが数多く存在します。(以降、ビルド&バンドルなどの事前変換処理をプリプロセスと表記します。) こ
【追記情報】 2022/06/15 09:00 誤字修正 + cdkk8sについて言及 先日、ハンドブックを公開しました。 ここではKubernetes上で稼働させた実績値としての記録が紹介してあります。が、逆に紹介していないものもたくさんあります。検証が済んでいないもの、時間的制約から導入できなかったものなど、不完全な情報を紹介しようと思います。 したがって、何も保証するための裏付けはないので「そういうことも検討してたんだなぁ」ぐらいで読んでもらえると嬉しいです。元記事もぜひ読んでみてください。 nodejsのDocker Imageの軽量化 Docker Imageを作る際、多くの場合Image内にnode_modulesを含んだ状態でイメージを作成しています。Nodejsのベースイメージが60〜100MBくらいあるのに対して、ビルド後のイメージサイズは200MB〜1GBくらいまで膨れ
概要 Webpackを使ってNode.jsとブラウザに両対応したライブラリを作るときのレシピ集です いろいろなレシピを見てWebpackによるライブラリ生成の挙動を理解することを目的としています ブラウザにもNode.jsにも両対応したライブラリを作りたい ブラウザとNode.jsに両対応したいとおもったとき、 両方同時に対応した1つのバンドルjsを作る【統合型】と、 ブラウザ用、Node.js用と別々にライブラリを出し分ける【出し分け型】の2パターンある。 本稿では主に【統合型】について説明する ライブラリのビルドに関するWebpack設定項目 レシピ集に行く前に、 まず、ライブラリのビルドに関する設定項目をざっくりみていく。 webpack.config.js 以下のような典型的なwebpack.config.jsの中でoutput以下の項目でライブラリ生成のためのパラメータを決める。
r7kamura さんのこのサイトの実装 2020年版に倣って、このブログの実装を書いてみる。 ソースコードは全て GitHub に上げてある。 ホスティングとCI Cloudflare Workers を使って配信している。 CI は専用CLIツールの Wrangler の使い勝手がよく簡単。 GitHub Action も公式から提供されているのがあるのでそれを使うだけ。 TypeScript, React を使っているので Wrangler 組み込みの Webpack でビルドしている。 Webpack がどう動いているのかいまいち掴みきれてないので、 Wrangler のコードを読まないといけない。 投稿の管理 Markdown ファイルを自前で HTML に変換することはせず、GitHub Issues に書くことにした。 画像もサッと入れられるし、モバイルアプリ（GitHub
EventEmitterのようにPub/Subを行うeventmitという小さなライブラリを書きました。 azu/eventmit: Simple EventEmitter. A single event object per an event. eventmitは、TypeScriptで書かれています。 また、Node.jsのEventEmitterなどとは違って、イベント一つに対してeventmitのオブジェクトを一つ作成して使います。 import { eventmit } from "eventmit"; const event = eventmit<{ key: string }>(); // Register handler event.on((value) => { console.log(1, value); }); event.on((value) => { consol
今回は中身がどう動いているかを解説したいと思います。 最初のこの記事では、最低限の実装を説明していくことにします。 webpack のアルゴリズムの仕組みはこちらを読んでください。 必要なステップ 必要なステップは以下の 3 つです。 エントリーポイントからのすべてのモジュールを走査し、requireを解決後にユニーク id を付与していく コード内のモジュールパス(requireの引数(e.g. ./module.js))を id へ置換する runtime のコードテンプレートの作成 IIFE(即時関数)箇所とそれに付随する引数の module 群 この実装されあれば、動くコードはできます。(2 つめは optional でもいいけど後からつらくなる) モジュール解決 今回は説明しやすいように関数を 2 つに分けています。 すべてのモジュールの把握と ID 作成 コード内の requi
Rspack
Fast StartupCombining TypeScript and Rust with a parallelized architecture to bring you the ultimate developer experience.
最近Next.jsのドキュメントが更新されて、APIリファレンスが付くなど読みやすくなったので、この機会に全部読んでみた。メモを置いておく。 https://nextjs.org/docs/routing/introduction#dynamic-route-segments pages/post/[…all] → /post/* (/post/2020/id/title) こんなことできるのか！ただ全部吸い込まれるのは使いづらそう https://nextjs.org/docs/routing/shallow-routing router.pushにshallowオプションを加えると、getInitialPropsを実行しないレンダリングができる。ページ内でクエリやハッシュフラグメントを変えるなどで便利に使えそう import { useEffect } from 'react' imp
Babel 7.4.0で非推奨になった@babel/polyfillを使わず、core-js@3で環境構築する | nansystem
# Babel 7.4.0で非推奨になった@babel/polyfillを使わず、core-js@3で環境構築する @babel/polyfill (opens new window)のページにBabel 7.4.0から非推奨になったと書かれている。 As of Babel 7.4.0, this package has been deprecated この記事ではwebpack4でBabel7.4を使った環境構築の方法を記載する。 # 環境構築 # インストール @babel/polyfillではなくcore-jsとregenerator-runtimeをインストールしているのがポイント。 Polyfillはcore-jsにまとめられており、async-awaitを動かすにはregenerator-runtimeが別で必要になる。 そのほか、BabelやWebpackでビルドするために必
ABEMAにesbuildを導入してWebのバンドル処理を69倍高速化した話 | CyberAgent Developers Blog
こんにちは，テレビ＆ビデオエンターテインメント「ABEMA」で Web エンジニアをしている野口 (@nodaguti) です．今回は，ABEMA の開発組織で行われている「改善week」という制度を使って esbuild というバンドラーを ABEMA Web に導入し，開発ビルドのバンドル処理を最大 69 倍高速化した話をご紹介します． 改善weekとは ABEMA では事業の成長に合わせて機能開発も活発に行われています．そのため，今でもスプリントごとに新しい機能の追加や既存機能の改善など数多くの施策がリリースされています． 各事業施策は目標としている KPI の達成を目的として設計されています．それゆえに KPI と直接関連しにくい部分のデザイン改善やリファクタリング，開発体験 (DX) 向上などは施策の合間に行う形になりがちでした．また，アニメーションの見直しやアプリの Debug
webpack を使った code splitting のベストプラクティスとして，v3 以前の CommonsChunkPlugin の時代から node_modules 以下に置かれている依存ライブラリを vendor.js という単一の chunk にまとめる方法が紹介されていました． これは webpack の公式ドキュメント Caching | webpack や Google の Make use of long-term caching | Web Fundamentals | Google Developers でも説明されている通り，「ライブラリのコードはアプリケーションコードに比べると更新頻度が低い」という仮定のもと vendor.js にライブラリコードを切り出すことで，キャッシュ効率をよくすることが主な目的でした． しかし時は流れ，いつしか「ライブラリのコー
今回は graphql-codegen を使い説明します。今回の例は、graphql-codegen 以外でも発生する可能性がありますが自動生成系が一番顕著に影響がわかりやすいです。 graphql-codegen はよく、graphql のスキーマから typescript の型定義/react の hooks 等を自動生成するのに使われますが、これは next.js と組み合わせた場合、少しトリッキーな部分があります。 graphql-codegen はデフォルトでは 1 ファイルにすべて出力されますが、それに対し next.js は各ページを chunks として吐くため何も考えずに実装すると、バンドルされるファイル量が膨大になる可能性があります。next.config.js から webpack の設定を上書きできますが、optimization はかなり上書きしづらくそもそも上書
近頃のJavaScript開発は、モジュールとして書かれた複数のJavaScriptファイルをimport文やexport文を通じて連携させるのが基本です。また、それらのファイルはWebpackに代表されるバンドラによって事前に処理され、import文の解決・ファイルの結合といった前処理を施されるのが普通です。まったく、各ファイルが他に影響を与えないように(function(){ ... })()で囲んで文字列連結していた時代が懐かしいですね。 さて、import文の解決を担当するバンドラは、大抵JavaScriptプログラム以外のものを読み込む機能を備えています。Webpackならばloaderと呼ばれるものですね。例えば、style-loaderやcss-loaderが持つCSS Modulesの機能を使うと次のようなプログラムを書くことができます（Reactの例）。 import s
webpack4系から5系にアップデートした際の対応事項とかメモ - Madogiwa Blog
個人で開発しているサービスでフロントエンドのbuildにwebpackを利用しているのですが、4系から5系にアップデートしたので、そのあたりで対応したことをメモしておきます📝 利用していたwebpackのビルド構成 webpackアップデート時の対応事項メモ modeを明示的に指定するようにした デフォルトでinstallされなくなったNode.js系のpolyfilをinstallした [hash]ではなく[contenthash]を利用するようにした その他の対応事項 webpack-assets-manifestのデフォルトのファイルパスが変わる おわりに 利用していたwebpackのビルド構成 基本的には以下のようなライブラリを利用したBabel + TypeScript + Vueで、 mini-css-extract-pluginでcssを別ファイルで生成するようにして、we
TypeScriptでCLIツール作りをするためのプロジェクトサンプルを作ってみた - $shibayu36->blog;
最近TypeScriptの学習をしようと思い、何でもTypeScriptで作ってみている。今回はCLIツールを作ろうと思ったのだが、ビルド環境やeslint環境など考えることが結構あった。そこでTypeScriptでのCLIツールのプロジェクトサンプルを作りながら勉強してみた。 作成したのは https://github.com/shibayu36/typescript-cli-project 。 npm install -g shibayu36/typescript-cli-project でtypescript-cli-projectというコマンドがインストールされ実行できるようになった。 このプロジェクトサンプル作成を通して学んだことをメモしておく。 参考文献 以下2つの文献が入門として非常に参考になった。この2つの文献を参考にしつつ、公式ドキュメントを追いかけながら作成していった。
Web アプリケーション開発において TypeScript で型付けをして、 React, Vue, Angular などのフレームワークでビューを作り、 Webpack でバンドルする、という構成が当たり前のようになってから久しいですね。 フロントエンドアプリケーションの設計は洗練され、我々はまあまあ安全かつ開発しやすい環境でアプリケーションを作れるようになりました。 ところでみなさんはその開発環境の構築にどれだけのコストをかけていますか？ 新規プロダクトを作るたびに最適な Webpack の設定ファイルを作るために苦心して、気づけばその肉体にゴリゴリのウェブパッ筋を宿していませんか？ 賢い人はスターターボイラープレート的なものを自分で用意しているかもしれません。 だけどそれも頻繁な依存ライブラリのアップデートに合わせるために常にメンテナンスが必要となります。カビの生えないボイラープレー
Vercel、Webpack後継を目指す、Rustベースの「Turbopack」をリリース JavaScriptフレームワークNext.jsの開発などで知られるホスティングサービス企業Vercelは2022年10月25日、Rustベースで高速に動作する新たなモジュールバンドラ「Turbopack」をリリースした。これはNext.jsでのアプリ開発を高速化するため、JavaScriptモジュールバンドラWebpackを置き換えるもの。 Webpackの700倍の速さを実現 同社によると、大規模なアプリケーションではTurbopackはWebpackの700倍高速に更新が表示されるとのこと。これは同社のビルドツールTurborepoなどで培われた各種キャッシュ最適化の技術を用いて実現されている。 TurbopackをNext.js 13開発サーバーで使用することで、超高速なホットリロード（HM
Webサービス開発の文脈で、モノレポ環境を作る方法について整理しました。 ※バックエンドもフロントエンドも全てTypeScriptで開発している前提 この記事を書いた背景 世間で言われる「モノレポ」がどのように達成されているのか知らなかった 参考記事を読んでると実現方法が異なっていたり、運用のイメージが見えなかったり、ベストプラクティスが分かりづらかった Turborepoのようなモノレポツールを導入すれば解決しそうだが、このツールが何をしてくれるのか理解できなかった モノレポ何も分からない………になった この記事ではモノレポに関連する仕組みを1つ1つ丁寧に把握し、最終的に理想的なモノレポ環境を実現することを目指します。 モノレポとは？ まずは用語の整理から。 モノレポを素直に訳せば「1つのリポジトリ」という意味でしかなく、1つのリポジトリで開発していればそれは「モノレポ」と呼べそうです。
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
歴史から見るTypeScriptにおけるwebpackとBabelの必要性 - Qiita
HTMLコーディングでもReact+TypeScriptの開発体験を得る
Rust製の高速なwebpack互換バンドラ「Rspack」登場。現時点で5倍から10倍の性能向上
JavaScript エコシステムを維持する OSS の努力と課題
webpack@5で入るModule Federationについて - hiroppy's site
webpack@5で入るPersistent Cachingについて - hiroppy's site
省ビルドサイズ要求環境でモダンフロントエンドをやる (主に preact の話)
メルカリアプリのWebView向けWebアプリケーションの開発を支えるモック技術
【実装メモ】Gatsbyを使ってよかった・注意すべき点まとめ - コネヒト開発者ブログ
Webpackをシンプルに理解しよう - Qiita
webpack のコード分割の初歩 - 30歳からのプログラミング
webpackの次のバージョンで入るassetModulesの紹介 - hiroppy's site
2行でwebpack.config.jsで補完を効かせる方法 - Qiita
Native ESM + TypeScript 拡張子問題: 歯にものが挟まったようなスッキリしない書き流し
2020 年の瀬の JS ビルド＆バンドルツールの検討
guijs
大規模サービスのBFFサーバーをKubernetesに移行した記事で書いていないこと
ブラウザとnode.jsに両対応したライブラリを作りたいときのWebpackレシピ集 - Qiita
2020-11-08 このブログの実装 2020年版 - waka.dev
小さなEventEmitterライブラリ - eventmitを書いた
module bundlerの作り方(準備編) - hiroppy's site
Next.jsのドキュメントを全部読んでみた - $shibayu36->blog;
vendor.js の終焉と Granular Chunks - 徒然技術日記
next.jsでのファイルチャンク最適化の一例 - hiroppy's site
import文で画像やCSSを読み込むのはECMAScript仕様違反か - uhyo/blog
Snowpack で実現する未来のフロントエンド開発 - Qiita
Vercel、Webpack後継を目指す、Rustベースの「Turbopack」をリリース | gihyo.jp
Webサービス開発でのmonorepo環境(Turborepo, nx)
anond.hatelabo.jp
www.asahi.com
hamakore.yokohama
ogawaqchan.xsrv.jp
www.hodinkee.jp
www.hodinkee.jp