実践 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) は実質的に
HTMLコーディングでもReact+TypeScriptの開発体験を得る
前置き 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 =
2020 年の瀬の JS ビルド＆バンドルツールの検討
今年から ZOZO テクノロジーズの Web エンジニアになりました。@takewell です。 もう年の瀬になりました。一年は早いですがブラウザの寿命は存外長いです。 来年はきっと Internet Explorer のサポートブラウザから外すことができるかもしれない。来年はわざわざツールを介さずとも ECMAScript 202X が動くブラウザが世界中のみなさんに使われるようになるかもしれない。そう願ってなりませんが、現実はそうではありません。 こうした課題を少しでもマシにするために webpack (シェア 76%)を代表とする ESNext (ECMAScript Next Generation) なコードをレガシーブラウザにビルドしたり、コードを単一ファイルにバンドルしたりするツールが数多く存在します。(以降、ビルド&バンドルなどの事前変換処理をプリプロセスと表記します。) こ
Webpack チャンク最適 テクニック - Qiita
ターゲット 巨大なSPAを作ってしまった人へ 巨大なSPAを作らないように気をつけたい人へ 今回はJSだけにフォーカスするが、もっというと、 超速本 を読んでください。 注意：本資料は、webpack チャンクの挙動を概念的に説明することを重視しているので、 webpack の詳細な設定や、出力ファイル名などは実際の処理と一致しない。適宜自分の手元にある設定とすり合わせるように。 昨今のJSビルド問題と、その解決のためのゴール設定 巨大なJS(+最近は in JS された各種SVGやCSS)はダウンロードだけではなく、UIスレッドのCPUをブロックする。 これはとくにCPUが貧弱な端末で体験が悪化する。そしてビルド時間で開発者体験を阻害する。 できれば webpack 推奨の 144kb 以内にしたい…が現実的に難しいので、 せめて 350kb ぐらいに抑えたい。 SPAなら (ローディン
【JavaScript】ビルドとは何か〜webpackを使ってビルドする - Qiita
この辺が曖昧だったので、書き残しておきます。 ビルドとは何か なぜビルドが必要か ビルドでは何を行なっているのか ビルドしたらどうなるのか Node.jsの特徴 JavaScriptをサーバーサイドで動かすための実行環境。 モジュール機能（他ファイルの読み込み） ノンブロッキングI/Oで処理を効率化 参考記事 ノンブロッキングI/O (non-blocking I/O) ノンブロッキングI/Oと非同期I/Oの違いを理解する Node.js を5分で大雑把に理解する Node.jsについて調べてみた JavaScriptが辿った変遷 npm とか bower とか一体何なんだよ！Javascript 界隈の文脈を理解しよう ビルドツール Node.jsスタイルのコードは、そのままの状態ではブラウザで動きません。ソースコードを元にして、実際に動くプログラム（実行可能ファイル）を作ってあげる必要
Nuxtプロジェクト内で使われてないコンポーネントを探す - じまろぐ
プロジェクトが進むと役目を終えた使わないコンポーネントが出てくる 放置していくとどれが使っててどれが使ってないかわからなくなってくる 使わなくなったコンポーネントの代わりに作られたコンポーネントの名前が似てると最悪みがある 「このコンポーネントだろう」と思って変更してみたら「残念！そっちじゃありません！」みたいなやつ 使わなくなったタイミングで削除するのがベストだけどそうもいかないのが現実 という感じで、使われなくなったコンポーネントを削除したい。 使われなくなったコンポーネントを見つける webpackのプラグインでビルド時に使われていないコンポーネントが探せる。 unused-files-webpack-pluginを使って一覧を出す github.com nuxt.config.js の build.plugins に追記する。 const { UnusedFilesWebpackP
ServiceWorker内でBabelを駆使して、JavaScriptをビルドする - ログミーTech（テック）
2018年9月5日、第70回となる「HTML5とか勉強会」が開催されました。今回のテーマは「開発環境」。 Webフロントエンドの開発環境をテーマに、エディタプラクティスやServiceWorkerを開発ツールとして使うアプローチ、長期運用されたサービスのリニューアル方針など、登壇者たちがその知見を語ります。プレゼンテーション「ServiceWorker Side XXX」に登場したのは、mizchi氏。ServiceWorkerを駆使したある取り組みについて紹介します。講演資料はこちら 開発環境のためにServiceWorkerを使う mizchi氏（以下、mizchi）：では「ServiceWorker Side XXX」ということで発表させていただきます。mizchiです。よろしくお願いします。 （会場拍手） ちょっと自己紹介とかはする気ないんですけど、最近本を書いたので、その紹介だけ
ちゃんと理解するCode Splitting - Qiita
Code Splitting、サボってきたのですが、必要になりそうだったので真面目に調べてみました。 これからCode Splittingやりたい方の入口的な役割になれれば幸いです。 Code Splittingとはなにか Code Splittingはその名の通り「コードを分割すること」を指します。分割されたコードはユーザのアクションに応じて非同期に読み込まれます。 ちなみにWebpackでentry point分けることとかもCode Splittingと言えばそうなのですが、本記事では触れません。また、別にSPAでなくともCode Splittingはパフォーマンス向上に利用できますが、これ以降はSPAを前提に話します。 Code Splittingの目的 Code Splittingの目的は初期表示にかかる時間、及びユーザがインタラクションできるようになるまでの時間の削減です。 S
【ChromeExtension】 'unsafe-eval' エラーの解決方法 - 人生dat落ち
Chrome Extension を開発していたらoptionページで次のエラーが出ました。 Uncaught EvalError: Refused to evaluate a string as JavaScript because 'unsafe-eval' is not an allowed source of script in the following Content Security Policy directive: "script-src 'self' blob: filesystem: chrome-extension-resource:" 原因CDN 経由で JavaScript ファイルを読み込んでいるからとか、 <script>タグ内に直接 JavaScript のソースコードを埋め込んでいるからとか色々出てくる。 そういう時はmanifest.jsonにポリシー
Markdownだけで綺麗なスライドを作るCLIを作っている - 技術探し
テーマ やりたかったこと デモ 手順 タスク 仕組み できること・できないこと できること できないこと 次の実装 さいごに fusuma0.0.1をリリースした。https://t.co/EpS9Wkq7DT— npx hiroppy😶 (@about_hiroppy) 2018年4月27日 今現在、0.2.1 テーマ 本質ではないwebpackとかBabelとかPostcssとかの設定ファイルを書くことなく、1コマンドでリリースまで面倒を見てくれて、マークダウンだけクールなスライドを作れるようにしたい。 サッとスライドを作れて、サッっとデプロイしたい。 やりたかったこと webpackやBabelの設定を隠蔽したい 開発・プロダクトビルド・リリースを1コマンドで終わらせたい マークダウン(or HTML)で書けるようにしたい フレームワークへの接続 bespoke.js以外にも対応さ
webpack 4 の optimization.splitChunks の使い方、使い所 〜廃止された CommonsChunkPlugin から移行する〜 - Qiita
webpack 4 の optimization.splitChunks の使い方、使い所 〜廃止された CommonsChunkPlugin から移行する〜JavaScriptwebpack はじめに 先日リリースされたwebpack 4でCommonsChunkPluginは廃止されました（CommonsChunkPluginの解説はこちら）。 その代わりとした追加されたoptimization.splitChunksの基本的な使い方、使い所に関しての記事です。 optimization.splitChunksを利用すればサイトパフォーマンスの改善（詳細は後述）ができるため、利用する機会が多い設定（機能）です。 解説に利用しているコードの最終形態はGitHub上にあります。 hira777/webpack-split-chunks-example webpackを理解していることを前提
すべてをjsにまとめる思想を理解する - webpackハンズオンシリーズ｜こんぴゅ
javascriptの開発では、sassやtypescriptなどのコンパイル、minifyやautoprefixerでの最適化、依存関係を解決しbundleするなど多様な工程があるので、属人化・職人依存を避けるためにタスクランナーでの自動化が昔から当たり前に行われています。 webpackはこの手のツールのデファクトです。webpackはタスクの自動化支援ではなく、なんでもjsにまとめるという仕事をうまくやる事に特化しています。gulpやbrowserifyで行なっていたようなタスクの自動化はnpm scriptで十分やん、という割り切りを感じます。 なんでもjsで扱えるようにするので、cssや画像やhtmlもjs内にロードでき、設定が煩雑になりにくくなります。 webpackのloaderという仕組みがjsへの組み込みや最適化をうまくやってくれるのですが、どういうものか検証していきまし
React 入門 - webpack 導入編 - Qiita
React に入門するために webpack で一から開発環境を作ってみた話です この記事を読むとわかること React の導入前に最低限必要な周辺ツールの概要 周辺ツールを入れるための webpack.config などの記述方法 フロントエンドの技術を把握する大変さ 動機 React プロジェクトの webpack を最新バージョンに上げたい しかし webpack.config の記述方法が大幅に変わっている さらに人の書いたコードを流用していたため解読できない箇所が多々ある それなら習作を兼ねて一から再入門してみよう！ 今回は理解を深めることが目的なので create-react-app のようなツールは使用しません 最低限必要なツールとは 以下のような要件が満たされる程度を想定しています : ビルドできる npm モジュールを利用できる コードの依存関係を解決できる スタイルシー
普通のRailsアプリケーションにReactを導入する | DevelopersIO
次にreactをインストールします。 $ npm install -S react react-dom package.jsonは以下のようになりました。 { (中略) "devDependencies": { "babel-core": "^6.21.0", "babel-loader": "^6.2.10", "babel-preset-es2015": "^6.18.0", "babel-preset-react": "^6.16.0", "webpack": "^1.14.0" }, "dependencies": { "react": "^15.4.2", "react-dom": "^15.4.2", }, (中略) } ビルド設定 webpackでビルドできるように設定ファイルを作ります。 clientディレクトリにwebpack.config.jsファイルを作成し以下の内容
フロントエンド知らない私のwebpack入門 その1 - Qiita
jQuery 1.7 あたりで知識が止まっている、最近のフロントエンド開発を知らない私が入門しています、という記事です。 なんか長くなったし、気力も持たないので、その1ということで書いています。 webpackってなあに？ npm経由で入るアセットバンドラー (asset bundler)です。Webフロントエンド開発用のビルドツールです。 SPAなどを作る時、 HTML・JS・CSS・画像やウェブフォントなど一連のリソースをまとめてくっつけたり、 くっつけられるように加工したり、 JSをbabelで古いブラウザ向けに変換したり、 TypeScriptやらをJSに変換したり、 全部面倒見てくれます。 ただwebpackに上記の機能を全て内蔵しているわけもなく、プラグインやローダーとかいった追加の機能をプロジェクトにインストールして設定することにより利用できるようになります。 最近のフロント
React、Angularになじめなかった僕に手を差し伸べてくれたVue.js - Qiita
ギークハウス Advent Calendar 2016の12月２２日の記事です。 他の方とは、全然違う雰囲気になってしまいましたが、読んでいただけると幸いです。 なぜVue.js？？ 普段の仕事では、Ruby/Railsなので、フロントエンド周りは、jQueryにCoffeeScriptで片手間感覚... ↓ しかし最近のフロントエンド界隈は、良くも悪くも盛り上がっていて楽しそうだなあと思う日々。 ↓ いろいろ、ググって調べてみると、ES6、Babel、Reactふむふむ...🤔 ん？？ Webpack? JSX?? Flux?? Redux?? 「落ち着け！とりあえず日本語でOK」状態。。正にこの記事で書かれている状態そのものでした。 ↓ Reactとかでイケてるフロントエンド開発をちょっと試したいと思っても、BabelやWebpackの設定など環境構築でつまづき、肝心のアプリケーショ
大規模プロダクトにおけるフロントエンドの1年間の変化 - Qiita
プロダクトに関わるエンジニアは40人近くいて、弊社ではフロントエンド/サーバーサイドといった明確な線引きがないため全員がフロントエンドに触れる機会が有りえます。開発チーム・コード共にそれなりに大規模と言えるのではないでしょうか。 やったこと モジュール間の依存解決 もともとRailsのSprocketsに沿ってjsを書いていたため、classは全て一つのグローバル変数に格納され、全てのjsが結合された巨大なapplication.jsをロードしている状態で、メンテナビリティやパフォーマンスに大きな問題を抱えていました。そこで去年よりWebpackを導入し、各モジュールの依存関係を整理してjsファイルを適切な単位に分割するようにしました。ファイル数が多いため段階的に作業をつづけ、今年ようやく全てのファイルの依存解決が完了することができました。 過渡期はWebpackとSprockets両方か
社内でCSSの新しい方針について話したメモ - Qiita
社内で新しいドメインを設立するにあたり、CSS Modules, PostCSS, cssnextを試してみました。 このスライドは、その際の説明に使ったものです。せっかくなので公開します。 「プロトタイプ作成で試してみたけど、みなさんどう思いますか？」くらいの温度感。本番採用が確定したわけではありません。何かお役に立つことがアレば幸いです。 以後、説明に使ったスライド。 おしながき 1. コンポーネント時代のスタイリング 2. グローバルCSS、BEM、そしてローカルCSS 3. CSS Modules、そしてJSXへの割り振り 4. cssnextと、その書き方 5. 我々のPostCSSスタンダード 新ドメインの CSS環境（案） CSS Modules css next PostCSS on webpack 何が変わるのか 我々の今までのスタイリング sassで書く スタイルのモジ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
hirata.blog