npm-scripts を書く時の手癖 - mizdra's blog
かれこれ 5 年くらい趣味開発で npm-scripts を書き続けている。長年書き続けているとノウハウが蓄積されてきて、「こう書くとスッキリする」「迷いがなくなる」「後から拡張したくなった時に、簡単に拡張できる」みたいな書き方が身についてきた。自分の型、あるいは手癖のようなものだと思う。 せっかくなので、id:mizdra の今の npm-scripts を書く時の手癖を書き連ねてみる。 基本形 { "scripts": { "build": "webpack --mode production", "dev": "webpack-dev-server --mode development", "lint": "eslint .", "test": "jest" } } 一番シンプルな npm-scripts を書く時のパターン。以下の 4 つの script を登録している。 buil
webpack のコード分割の初歩 - 30歳からのプログラミング
JavaScript や TypeScript を使ってウェブアプリを提供する場合、開発時はimportやexportなどの ES Modules を使い、公開時はファイルをバンドルして公開することが多い。 以下の記事に書いたように、現在の主要なブラウザは ES Modules に対応してものの、バンドルせずに公開してしまうとパフォーマンスに悪影響を与える可能性がある。 numb86-tech.hatenablog.com ファイル数が増えれば増えるほど影響は深刻になるため、依存関係が深いライブラリを使っている場合などは、レイテンシが飛躍的に増加してしまう。 そのため、バンドルせずに公開するのは現実的ではない。 バンドルしてひとつのファイルにまとめてしまえば、JavaScript のダウンロードは一度で済む。 しかしそうすると今度は、バンドルファイルの肥大化という問題が発生する。 巨大なフ
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つの文献を参考にしつつ、公式ドキュメントを追いかけながら作成していった。
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 にその設定が必要となるので、まだまだお世話になり続けるでしょう。 そんな利用
JavaScriptとTypeScriptを共存させ、段階的に移行する方法
某サービスのフロントエンド開発に携わるようになってからずっと考えていることがある。 TypeScriptに移行して、型に守られたい！ ただ稼働しているサービスをいっきにTypeScriptに移行するのは危険で膨大な工数がかかるため、段階的に移行できないかと考えた。 ということでJavaScriptとTypeScriptを共存させる方法をまとめる。 環境は以下のとおり。 webpack@4.0.1 webpack-cli@2.0.9 webpack v3系の場合は不要 typescript@2.7.2 ts-loader@4.0.0 ※ あとでbabel-loaderについて追記予定です！ → 2018/03/23 追記しました 移行前の状態 極小サンプルを使って紹介する。 // src/main.js import { add } from './module' const result
俺の webpack.config.js-20200503 - mizchi's blog
基本思想 とにかく薄く。必要なものだけ。基本は ts-loader を transpileOnly: true で使うだけ。最悪これだけでいい。型チェックはIDEか yarn tsc -p . --noEmit でやる。 CRA や parcel は使わない。暗黙な振る舞いが多すぎるので。一切勉強したくない人はいれていいと思うが、その場合 eject しない、dist ディレクトリをそのまま使うこと前提。 style-loader/css-loader は外部CSSを読むときに設定する worker-plugin はなくてもいいけど、 worker もビルドしたいことが多いので、入れていることが多い html-webpack-plugin と webpack-dev-server 組み合わせると、他と組み合わせずに完結して動く。このHTMLを本番で使わずとも、デバッグで使ってることが多いの
TypeScript で複数のモジュールをまとめて export, import する
TypeScript を使って Node.js のアプリを開発していると、だんだんモジュールの数が増えていき、export, import 文が長くなったり冗長な感じになったりします。また、プロジェクト全体の共通機能をまとめてモジュール化する仕組みを考えたりと、モジュールの構成をどうするかについては常々悩ましいところがあります。 この記事では、モジュール構成のリファクタリングに使えるre-exportsとそれを import する方法について紹介します。元々は ES Modules の仕様なので、Interface など TypeScript の機能を除き JS でも同じく使える仕組みになります。 ※ただし、ES Modules の構文（JS）をそのまま Node.js 上で実行する場合は mjs 拡張子の使用・実験フラグ付きの起動が必要になり、詳細については割愛させていただきます。 ex
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でビルドするために必
ライブラリ開発のための環境設定 — 仕事ですぐに使えるTypeScript ドキュメント
module.exports = { module: { rules: [ { test: /\.js$/, use: "babel-loader", exclude: /node_modules/ } ] } }; なお、ライブラリの場合は特別な場合を除いてBabelもwebpackもいりません。CommonJS形式で出しておけば、Node.jsで実行するだけなら問題ありませんし、基本的にwebpackとかrollup.jsとかのバンドラーを使って1ファイルにまとめるのは、最終的なアプリケーション作成者の責務となります。特別な場合というのは、Babelプラグインで加工が必要なJSS in JSとかですが、ここでは一旦おいておきます。ただし、JSXはTypeScriptの処理系自身で処理できるので不要です。 TypeScriptユーザーがライブラリを使う場合、バンドルされていない場合は @
パッケージはBundleを配布しない · Webフロントエンド パフォーマンス改善ハンドブック
パッケージはBundleを配布しない ニコニコ生放送 PCのHTML5プレイヤーは、基本的にはTypeScriptで書かれていてビルドにはwebpack + tsloaderという構造になっています。 webpackでビルドされているのでWebpack Bundle Analyzerを使い、ビルドしたパッケージの依存をビジュアライズして調査しました。 Webpack Bundle Analyzer 実際の改善前のbundleしたファイル構造は次のような形でした。 @nicoliveから始まるものは社内のnpmレジストリに公開されている社内モジュールです。 この社内モジュールがlib/index.jsという大きな1つファイルしか持っていないことがわかります。 これは、各パッケージがbundle済みのファイルをlib/index.jsとして配布するようになっていたためです。また、そのbundl
モダン JavaScript プログラミングを始めるために知っておきたい技術セット - Qiita
元々は社内向けとして書いたものですが、転載許可が出たので Qiita 向けに加筆・修正した文章です。 僕は普段ペチパーバックエンド領域を担当することが多いのですが、フロントエンド領域を含めて社内の技術アップデートを一緒に頑張っていきたい、という思いから書きました。 なんせペチパーバックエンドエンジニアの拙い知識なので一部情報が古かったり間違っているかもしれません。 フロントエンドガチ勢の皆様、間違い等ございましたら温かく指摘して頂ければと思います。 前書き JavaScript は一応書けるけど、将来心配。なんかすごく進化してるって聞くけど、調べてみても訳が分からない。 僕も勉強し始めは同じことを何度も思いました。 そこで、僕の仕事環境を想定し、導入すべきツールを役割ごとに選定してみました。 上から順に読んで、インストールして、使えるようになるとそれなりにモダンなフロントエンドの知識を手に
webpackの仕組みを簡潔に説明する - hiroppy's site
この記事は、Node.js Advent Calendar 2018の 18 日目の記事です。 遅れてしまい本当に申し訳ありません。 この記事は、HTML5 カンファレンスで話した内容が中心となります。 Node.js とはかけ離れていますが、自分が書きたかった内容だったので、理解してくださると嬉しいです。 モジュール webpack は以下のモジュールをサポートします。 // ESM (ECMAScript Modules) import foo from "./foo"; export default foo; import("./foo.wasm"); // native support for WebAssembly import("./foo.json"); // native support for JSON // CJS (CommonJS Modules) const fo
Webpack の考え方について - mizchi's blog
なぜ初心者は webpackが解らないのか？- Why can’t you understand the webpack? - from 健人 井関 www.slideshare.net この記事バズってたけど、わからない人がよりわからなくなる、という点で問題だと思っていて、webpack の目的の本質的な部分から整理する必要があると思います。 (あと友人が webpack に挑戦していたので入門資料も兼ねてる) Webpack の本質的な部分は次の3つです。それ以外は全部おまけ機能だと思ってよいです。 ES Modules のエミュレート node_modules のリンカ 拡張子ごとの変形 Webpack が本当にやりたいこと こういうコードがあるとします。 // src/a.js export default () => console.log('hello'); // src/in
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
