Background When a user writes a module specifier (the string literal after from in an import declaration) in a TypeScript file, how should the compiler resolve that string to a file on disk to be included in type checking? Because TypeScript never rewrites module specifiers in its JavaScript emit, the only possible answer is that it should mirror whatever resolution behavior the code’s intended ru
I get this error when reloading my Chrome Extension after compiling using Webpack: 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:". at new Function (<anonymous>) at evalExpression (compiler.js:33919) at jitState
It has been nearly 2 months since webpack 5 was officially released. Due to the sponsoring situation, we couldn't devote as much time to webpack as we would like to. Speaking only for myself (@sokra), I enjoyed the little break and have worked on a few side projects. Ironically, while I was using webpack 5 and all its bleeding-edge features (asset modules, worker support, persistent caching), I di
ESM-CJS interop test Test Cases Results Node.js Babel Webpack Rollup.js Parcel esbuild Results by test case Results by syntax import x and similar import { named } and similar import { __esModule } and similar import * and similar import() and similar require().default and similar require().named and similar require().__esModule and similar require() and similar Direct differences Webpack <-> Node
Webpack no longer automatically polyfills Node.js APIs. This is a huge breaking change and will inconvenience both users and package maintainers. Most packages on npm are mainly made with Node.js in mind. However, thanks to automatic polyfilling, most of them have for years worked fine in the browser too. The problem is that Webpack created convenience by automatically polyfilling and then now sud
The motivation for Module Federation is developing one or more applications with multiple teams. Applications are split into smaller application "parts". These could be frontend components like a "Header" or "Sidebar" component, but also logical components like "Data Fetching Logic" or other business logic. Each part can be developed by a separate team. Applications or parts of them share other pa
近頃のJavaScript開発は、モジュールとして書かれた複数のJavaScriptファイルをimport文やexport文を通じて連携させるのが基本です。また、それらのファイルはWebpackに代表されるバンドラによって事前に処理され、import文の解決・ファイルの結合といった前処理を施されるのが普通です。まったく、各ファイルが他に影響を与えないように(function(){ ... })()で囲んで文字列連結していた時代が懐かしいですね。 さて、import文の解決を担当するバンドラは、大抵JavaScriptプログラム以外のものを読み込む機能を備えています。Webpackならばloaderと呼ばれるものですね。例えば、style-loaderやcss-loaderが持つCSS Modulesの機能を使うと次のようなプログラムを書くことができます(Reactの例)。 import s
この機能が導入されることにより、{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
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く