power-assert-monorepo/packages/node at main · twada/power-assert-monorepoYou signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
（2023/06）Jest における CommonJS / ECMAScript Modules の扱いについて - Qiita
1. 概要 JavaScript における CommonJS（以下、CJS）と ECMAScript Modules（以下、ESM）の問題は色々なところで発生する厄介な問題です。 Jest を使ったテストコードにおいてもこの問題に直面することがあります。 この文章は Jest における CommonJS / ECMAScript Modules の扱いについて包括的な情報提供を目指して書いています。 これを書くにあたって私は様々な情報収集をした他、不明瞭なところは実験サンプルを作って動きをみたり、関連するモジュールの中身を見てみたり、色々なことをしています。 正確な記載を心掛けますが、間違いを発見した場合は遠慮なく指摘をしてください。しかし、Node.js の世界は進歩が速いので受けた指摘をこの文章に反映するかどうかはわからないことを予め申し上げておきます。 基本的にはこの文章は執筆時点の
Node.jsで機能やパッケージの非推奨メッセージを通知する方法
ライブラリやツールなどを作っているときに、特定の機能やパッケージを非推奨にする場合があります。 これらの非推奨はリポジトリ上のREADMEやIssueなどに書いても、利用者が気づかないことがあります。 そのため、利用者が気付けるように非推奨の機能やパッケージを使った場合に警告を出す方法を紹介します。 非推奨にはいくつかの段階があり、それに応じてやり方を変えられるので、それぞれの方法を紹介します。 パッケージの非推奨化: npm deprecate <package> <message> コードレベルの非推奨化: JSDocタグの@deprecated 実行時の非推奨化: process.emitWarning() パッケージの非推奨化: npm deprecate <package> <message> npmのパッケージレベルで、そのパッケージが非推奨であることを通知するにはnpm de
mise (旧 rtx) で脱 node-build (asdf)
年明けはまず環境整備から、ということで今年は mise を導入することにした。 去年まで rtx とか rtx-cli という名前でやってた Rust 実装の asdf 代替の多用途バージョン管理ツール。この年明けに急に mise にリネームしたよ、というニュースが流れてきて、気になって見てみたら良さそうだった。 一般的な解説は "rtx" でググると日本語記事も出てくるのでそっちを見て欲しいけど、個人的な asdf に対するメリットはこのあたり。 とにかく速い asdf は Node の最新バージョンの反映が node-build 依存で、更新が数日遅れることがあった 結果的に手動で定義ファイルを更新していたが、処理速度も遅く面倒だった 参考: asdf で node-build の定義ファイルを手動更新する asdf はコマンド体系が謎だった（自分には） 例えば v20 系の最新をイン
Deno + dntでCJS・ESMに対応したnpmパッケージを作ろう
3 行まとめ CJS、ESM に対応した npm パッケージが Deno + dntで簡単に作成できる Deno で開発できるので、Lint、Format、Test、TypeCheck が設定なしですぐに使える dntで作成した CJS、ESM のファイルに対して、それぞれ Node.js でもテストを実行してくれる Deno のモジュールを npm パッケージに変換するdnt Deno のdntモジュールを使うと、Deno で実装したモジュールを CommonJS(CJS) と ESM、TypeScript に対応した npm パッケージとして公開できます。 実際、今回 Deno とdntを試してみましたが、Deno には Linter、Formatter、Test などが組み込まれているので、すぐに npm パッケージの作成に取り掛かれるのが良かったです。また、CICD の自動化(Gi
CommonJSからES Modulesへの移行する方法。トップダウンかボトムアップか
Secretlint v7でCommonJS からES Modulesへの移行を行いました。 Secretlint v7.0.0をリリースしました。Pure ESMへの書き直し この記事では、CommonJS(CJS)からES Modules(ESM)への移行を行った経緯と、移行する方法について紹介します。 CJSからESMへの移行は、率直に言えば単調な作業で、メリットが見えにくい作業です。 しかし、将来的にCJSよりもESMが主流になることは間違いないので、移行することは必要です。 移行の作業は、移行方法が決まれば大部分は機械的な書き換えが可能です。 では、実際にどうやって移行したのかを紹介します。 ESMへの移行の影響は依存元へと連鎖する Secretlintのリポジトリはmonorepoになっていて、だいたい40コぐらいのパッケージが含まれています。 そしてパッケージ間で依存関係があ
Secretlint v7.0.0をリリースしました。Pure ESMへの書き直し
機密情報をLintできるSecretlintのv7.0.0をリリースしました！ Release v7.0.0 · secretlint/secretlint このバージョンでは、SecretlintをESMモジュールとして書き直しました。 どのように移行したかは別の記事で紹介しているので、移行方法について記事を参照してください CommonJSからES Modulesへの移行する方法。トップダウンかボトムアップか Secretlint v7.0.0の変更点 ルールと本体のコードを含めて、全部のパッケージをESMに書き直しました。 その中で、いろいろ整理したりもしたので、変更点はいろいろあります。 ただし、secretlintコマンドや@secretlint/quick-start、Docker Imageとして使う場合は、そこまで目にみえる変化は少ないと思います。 詳細はリリースノートも参
node_modulesの問題点とその歴史 npm, yarnとpnpm
皆さんnpmパッケージのバージョンを上げるときにハマって依存地獄から抜けられなかったことはありませんか？ 私はあります。 複雑怪奇な依存関係を調べてみようとnode_modulesを覗いてみて、そのカオスっぷりに臭いものに蓋をしたことはありませんか？ 私はあります。 そこでnode_modules以下について調べてみたのですが、node_modulesにどんな問題点があって、npmやyarn, pnpmは何を目指していたのか時系列順に紐解いた方がわかりやすいことに気づきました。 ここでは初期のnpmが抱えていた問題から今に至るまでを順を追って説明します。 するとnode_modulesの仕組みの他に、各パッケージマネージャの方針の違いが見えてくるはずです。 初期の頃のnpm (~2015年以前) この頃はシンプルで、依存関係はそのままnode_modulesのディレクトリ構造に反映されてい
eslint-cjs-to-esm: CJSをESMへとマイグレーションするツールを書いた
最近、色々なライブラリをCommonJS(CJS)からECMAScript Module(ESM)へとマイグレーションしています。 その際に、ESMでは__dirnameやrequireなどCommonJS特有の機能は使えなくなっています。 また、TypeScriptやBabelなど多くのツールはCJSではimport時に拡張子はなくても大丈夫ですが、ESMの場合はimport時に拡張子が必要になります。 import url from "node:url"; - import { mdEscape } from "./mdEscape"; + import { mdEscape } from "./mdEscape.js"; // ESMでは相対パスに拡張子は省略できない + const __filename = url.fileURLToPath(import.meta.url); /
Node.jsコンテナイメージを極限まで軽量化! サイズを1/10以下に｜SHIFT Group 技術ブログ
はじめにSHIFT DAAE の shinagawa です。表題の通りNode.jsで作成したコンテナのイメージサイズの軽量化に挑戦しました。 背景近年の多様化・高速化するビジネスに対応するITシステムの構築を実現する「クラウドネイティブ」の構成要素の一つとして 「コンテナ」という仮想化技術が存在し、当部門でも活用を進めております。 このコンテナイメージを作成するにはアプリケーションコードやライブラリ・モジュールなどの依存物、ランタイム等を1つのイメージとして組み立てて作成しますが、 この構成要素が増えるとイメージサイズが肥大化し保管時のストレージのコストの増加やイメージの転送、環境への展開に時間がかかることになります。 従ってイメージのサイズを削減することは、これらの点を改善することにつながります。 ここではネット上で紹介されている、あらゆる打ち手を組み合わせてコンテナイメージの軽量化に
Node.jsのツールで--cacheフラグを実装するためのライブラリを書いた
ESLint、Prettierなどは--cacheフラグという一度チェックしたファイルは、ファイルが変更されるまで再チェックしないキャッシュの仕組みを実装しています。 同様の仕組みをtextlintを実装したことはありますが、file-entry-cacheを使い結構煩雑な実装が必要になります。ファイル変更を元に処理結果をキャッシュする仕組みはある程度定型化されているのに、毎回同じような実装をツールごとに書くのは微妙だなと思ったので、ライブラリを書きました。 azu/file-cache: Node.js library that provide a cache for file metadata or file content. --cacheフラグの仕組み --cacheフラグの仕組みとしては、ファイルの内容のハッシュ値 or ファイルの更新時刻をキャッシュファイルとして保存して置きま
Webサービス開発でのmonorepo環境(Turborepo, nx)
Webサービス開発の文脈で、モノレポ環境を作る方法について整理しました。 ※バックエンドもフロントエンドも全てTypeScriptで開発している前提 この記事を書いた背景 世間で言われる「モノレポ」がどのように達成されているのか知らなかった 参考記事を読んでると実現方法が異なっていたり、運用のイメージが見えなかったり、ベストプラクティスが分かりづらかった Turborepoのようなモノレポツールを導入すれば解決しそうだが、このツールが何をしてくれるのか理解できなかった モノレポ何も分からない………になった この記事ではモノレポに関連する仕組みを1つ1つ丁寧に把握し、最終的に理想的なモノレポ環境を実現することを目指します。 モノレポとは？ まずは用語の整理から。 モノレポを素直に訳せば「1つのリポジトリ」という意味でしかなく、1つのリポジトリで開発していればそれは「モノレポ」と呼べそうです。
npm/yarnの不足点とpnpmの解決法 - ミツモア Tech blog
※ こちらはミツモアAdvent Calendar 2021の6日目の記事です。 こんにちはミツモアで エンジニアの邢(@keidarcy)です。 ミツモアは「リモートワークが増えてエアコンを綺麗にしたい」「引っ越しで出た不用品を回収してもらいたい」といった生活のあらゆるシーンであなたにぴったりの専門家を無料で探せるサービスですので、ぜひ気軽に使ってみてください！ meetsmore.com pnpmとは pnpm 公式サイトによると、pnpmはperformant npmを表しています。 pnpm Fast, disk space efficient package manager なので、pnpmはnpm/yarn同じような存在です。現在（2021年12月）、たくさんメジャーのオープンソースプロジェクト（vue、prisma...）は pnpmを使用しています。本文はnpm/yarnの
npmの依存関係について勘違いしていたこと
はじめに 前回、上記の記事で「npm の依存関係と v7 のロックファイル」について調べた。 その後色々と調べたり試しているうちに、勘違いしていたことや分かっていなかったことがいくつもあったため、それらについてのまとめを作成したいと思う。 ChangeLog 2022-11-29 npm ci についての記述を追加 v8 と v9 についての記述を追加 pnpm などのシンボリックリンクベースのディレクトリ構造についての記述を追加 2022-03-30 リントミスを修正 誤字脱字・分かりにくい日本語などを修正 全体的に補足をいくつか追加 2022-03-31 Phantom dependencies についての記述を追加 そもそも 前回の記事では chalk や cowsay などパッケージを実際にインストールして、ロックファイルの構造や依存関係のことを調査した。その調査の結論としては、「
TypeScript におけるモジュール関連オプションの整理
TypeScript 4.7 で “module” という名前で始まる Compiler Option がさらに追加されて、さすがに何が何やら感あるので、役割を軽く整理。 この記事では雑な紹介に留めるので、それぞれの詳細は TSConfig Reference を読みに行ってください。 対応関係ソースコードとそれぞれのオプションが何に作用しているのかを雑に図示するとこんな感じ。 重要なことどのオプションをいじっても、import 指定子 (上図の “./hoge” の部分) がコンパイル時に書き換えられることはない。 これが頭に入っていれば、.mts, .cts といった TypeScript のファイルで import "./foo.cjs" と書くことや、 --moduleSuffixes がソースコードの探索にしか影響しないことに得心できるはず。 --moduleTypeScript
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
