タグ検索の該当結果が少ないため、タイトル検索結果を表示しています。
Secretlint v7でCommonJS からES Modulesへの移行を行いました。 Secretlint v7.0.0をリリースしました。Pure ESMへの書き直し この記事では、CommonJS(CJS)からES Modules(ESM)への移行を行った経緯と、移行する方法について紹介します。 CJSからESMへの移行は、率直に言えば単調な作業で、メリットが見えにくい作業です。 しかし、将来的にCJSよりもESMが主流になることは間違いないので、移行することは必要です。 移行の作業は、移行方法が決まれば大部分は機械的な書き換えが可能です。 では、実際にどうやって移行したのかを紹介します。 ESMへの移行の影響は依存元へと連鎖する Secretlintのリポジトリはmonorepoになっていて、だいたい40コぐらいのパッケージが含まれています。 そしてパッケージ間で依存関係があ
Bun.SQL now supports MySQL and SQLite, alongside PostgreSQL. Native YAML support. 500x faster postMessage(string). Bun.build() compile API, with... Reduced idle CPU usage. Improved `bun:test` diffing. Automatic `ETag` and `If-None-Match` in static routes for `Bun.serve`. 40x faster `AbortSig...
JavaScript, the undisputed king of web development, is being sabotaged — not by a rival language or a revolutionary new technology, but by its own baggage from the past. This insidious saboteur is none other than CommonJS, the antique module system that we’ve tolerated for far too long. The rise of CommonJS About 15 years after its invention, JavaScript started expanding beyond the browser to the
モチベーション 普段フロントエンドを領分にしているのになかなかこのあたりの基礎が足りていないと感じることが多いので、なんとかしたい。 ES Modules方式でしか対応されていないライブラリを使おうとしてコケたので色々調べたのも含め、まとめていく。 ちなみにその辺りについてはこの神記事見ると良い。 個人的に気になっているモジュールシステムについて掘り下げていく。 CommonJS CommonJSとは、サーバーサイドなどのウェブブラウザ環境外におけるJavaScriptの各種仕様を定めることを目標としたプロジェクトである。 from Wikipedia 例えばNode.jsで使われている。 Node.jsはデフォルトで全てのモジュールをCommonJSで扱うが、Node.jsは最近のバージョンでES Modulesに対応するなどしていて、潮流はES Modulesに流れつつある。 後述する
本記事はsyumai Advent Calendar 2024 4日目の記事です。 内容としては、主にWeb Developer Conference 2024の休憩中に@NozomuIkutaさんと行った雑談を記事化したものです。 内容に何か問題があれば、本記事のコメント欄や、Xなどでご連絡ください。 require(esm)の登場 2024年、ついにNode.jsのCommonJS modulesから、ES modulesを利用できるようになりました。 使い方は簡単で、これまでCommonJS modulesから別のCommonJS modulesを利用するために使っていた require をそのままES modulesに対して使います。 // ES modules側 (counter.mjs) let count = 0; export const currentCount = ()
Babel 7.14.0 is out! This release enables class fields and private methods by default (they were promoted to Stage 4 during the recent April TC39 meeting!) and adds brand checks for private fields and static class blocks to @babel/preset-env's shippedProposals option. We added support for Stage 1 async do expressions (using @babel/plugin-proposal-async-do-expressions), which extends the Stage 1 do
これをお読みの皆さんの中には、JavaScriptやTypeScript以外のプログラミング言語を経験したことがある人もいるかと思います。他の言語で、複数のモジュールシステムが共存している言語を使ったことはありますでしょうか。 JavaScriptには、系統が異なるモジュールシステムが、少なくとも2つ存在しています。ESモジュールとCommonJSです。こうした状況は、プログラミング言語としては、珍しいことです。JavaScriptのモジュールまわりを理解するのを難しくしている要因でもあります。 では、どうしてJavaScriptは2系統もモジュールシステムを持つようになったのでしょうか？ ここでは、JavaScriptの現状に至る流れを歴史からひも解いていきます。 ひとつめのモジュールシステム JavaScriptのモジュールシステムは、ブラウザよりも先んじて、サーバーサイドJavaSc
TypeScriptでExpressをちょびちょび弄ってて、Expressをimportする際esModuleinterop関連のエラーに引っかかったので、ついでによく分からなかったCommonJSやesModuleinteropフラグについて自分なりに調べてまとめておきます。 具体的にはtsconfig.jsonを作成しないで node_modules/@types/express/index.d.ts:116:1 116 export = e; This module is declared with using 'export =', and can only be used with a default import when using the 'esModuleInterop' flag. // このモジュールは 'export =' で宣言されており、'esModuleInt
こんにちは、CX事業本部 IoT事業部の若槻です。 今回は、TypeScriptでのCommonJSなモジュールの実行のエラーを、esModuleinteropフラグの設定により回避できたので、書き残しておきます。 事象 snakecase-keysを使ってオブジェクトのキーをスネークケースに変換するスクリプトを作成しました。 import snakecaseKeys from 'snakecase-keys'; const camel = { aaaBbb: 'ccc', dddEdd: 'fff' }; const snake = snakecaseKeys(camel); console.log(snake); しかしこのスクリプトを実行するとエラーとなってしまいます。 $ npx ts-node script.ts Need to install the following pac
はじめに 最近ではNode.jsのライブラリでも、pure ESMの考え方でES Moduleのみでしか利用できないものも出てきている。とはいえ、npm-esm-vs-cjsというリポジトリのデータによると、以下のようにCommonJSのライブラリのほうが圧倒的に多く、ES Moduleのみはまだ10％程度しかない（みたい）。 そこで、今回はライブラリを公開する際に、CommonJSとES Moduleの両方をサポートするようなプロジェクトの設定についてみていきたいと思う。 ※前提として、今回は1つのTypeScriptファイルからCommonJS・ES Moduleの両方に対応するJavaScriptファイルを作成することを考える（ファイル拡張子を".mts"や".cts"にして、コンパイル後のファイル拡張子を変えることでCommonJS・ES Moduleに対応する方法ではない）。その
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? JavaScriptの世界には、モジュールを扱うための2つの主要なシステムがあります。それが「CommonJS」と「ESモジュール（ECMAScript Modules）」です。どちらもコードを分割し、再利用可能にするための仕組みですが、いくつか重要な違いがあります。 📚 モジュールとは？ モジュールとは、特定の機能やデータを持つ独立したコードの単位のことです。モジュールにすることで、コードの可読性や保守性が向上し、大規模なアプリケーション開発がしやすくなります。🚀 🌟 CommonJS モジュール CommonJSは、主にNod
Node.js アプリケーションを CommonJS (CJS) から ES Modules (ESM) に移行したのでやったことを書き記します。 今回移行したアプリケーションは、バンドラーを伴わない純粋な Node.js アプリケーションです。TypeScript で書かれており、ビルド時には単に tsc で型を落としているだけです。ビルド成果物には require / module.exports が残っていて各ファイル同士が参照し合う、古典的なCJSアプリケーションとなります。 Node.js バージョンが 20 とやや古いので、残念ながら TypeScript のまま実行させること(--experimental-strip-types)はできません。よってこの記事では引き続き TypeScript を JavaScript に変換してから実行する場合の ESM 対応です。 tsco
先日、JTC-utils という CommonJS と ESM に対応したデュアルパッケージを公開したのですが、とてつもなく苦労したのでここにメモを残しておくことにします。 デュアルパッケージに対応するという記事はいくつかありますが、この記事は次の条件の時に役に立つと思います。 ソースコードは TypeScript で作りたい。 CommonJS と ESモジュールの両方に対応したい。 サブモジュール1を作りたい。（←ここ重要） 何がそんなに難しいのか TypeScript で作成したソースコードを CommonJS と ESモジュールにトランスパイルするため、ひとつのプロジェクト内に３つのソースコードが共存することになります。この時、次の条件が満たされる必要があります。 開発時に JavaScript が TypeScript の型付きで認識されなければならない ビルド時に TypeSc
Though browsers and JavaScript have come a long way, writing and publishing JavaScript modules is still painful. To maximize adoption, your module should support CommonJS and ESM, JavaScript with TypeScript declarations, and work in Deno, Node.js, and web browsers. To achieve that, many resort to complex release pipelines or maintaining two copies of code with slightly different module syntax. Wha
ES6, CommonJS, AMD, RequireJS, UMD, System.JS, TypeScriptのModule を完全に理解する JavaScript, TypeScriptを利用していると様々なモジュールシステムに関するワードが出てきます。 AMD, CommonJS, ES6, ES5, Webpack, Babel, RequireJS, UMD, SystemJS, System.register, module target etc... これらの用語の関係は複雑で混乱しがちな部分です。 この記事は、1つで全てを理解できる決定版を目指して記述しています。 少々長くなりますが、なんども振り返るノートとして利用していただければと思います。 では本題に入ります。 JavaScriptのModuleとは JavaScriptの新しい仕様ECMAScript2015(E
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 1. 概要 JavaScript における CommonJS（以下、CJS）と ECMAScript Modules（以下、ESM）の問題は色々なところで発生する厄介な問題です。 Jest を使ったテストコードにおいてもこの問題に直面することがあります。 この文章は Jest における CommonJS / ECMAScript Modules の扱いについて包括的な情報提供を目指して書いています。 これを書くにあたって私は様々な情報収集をした他、不明瞭なところは実験サンプルを作って動きをみたり、関連するモジュールの中身を見てみたり、色
こんにちは、21卒エンジニアの id:d-kimuson です。 先日、プロダクトで使用している lodash を lodash-es に置き換えることで、バンドルサイズの削減をしました。 lodash を lodash-es に置き換える話はよくありますが、今回のプロダクトは運用歴が長く CommonJS と ESModules が混在している少し特殊な環境での試みだったので、知見を共有したいと思います。 利用されていないコードを消し、バンドルサイズを減らす lodash はバンドルサイズの大きなライブラリです。minified な状態で 69.9KB のサイズになります。 参考: lodash v4.17.21 ❘ Bundlephobia webpack にはデッドコードを削除する TreeShaking という機能があり、ライブラリのデッドコードを削除することができるのでバンドルサ
ECMAScript modules (”ESM”) are the official, modern way of writing and sharing JavaScript — it’s supported in many environments (e.g. browsers, the edge, and modern runtimes like Deno), and offers a better development experience (e.g. async loading and being able to export without globals). While CommonJS was the standard for many years, supporting CommonJS today is hurting the JavaScript communit
Yesterday, I refactored Place1, which is a non-trivial Node.js app, to use ECMAScript Modules (ESM). Here’s a diff of the full set of changes. This is the approach I took and some of the issues I ran into, in case it helps someone else: Find and replace First off, I started by running the following regular expression2 to quickly convert CommonJS require syntax to ESM import syntax: Find const (.*?
10月17日、Denoは「CommonJSからESMへの変換方法」というブログ記事を公開した。ECMAScriptモジュール（ESM）は、最新かつ公式なJavaScriptの記述・共有方法であり、多くの環境（ブラウザ、エッジ、Denoのような最新のランタイム）でサポートされており、非同期ローディングやグローバル変数を使わずにエクスポートできるなど、開発体験も向上する。一方、CommonJSは長年にわたって標準とされてきたが、現在ではJavaScriptコミュニティにとって障害となっている。JavaScriptを将来的に見据えて開発するには、すべての新しいコードはESMで記述するべきである。しかし、互換性の理由から、レガシーコードベースを最新のパッケージに対応させるためにモダン化する必要がある場合もある。今回の公開内容では、レガシーなCommonJSプロジェクトをESMに対応させるための構文
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
