index

前回までのあらすじ

前回はnpm workspacesに再入門したうえで、Turborepoとの違いを確認した。

今回はnpm workspacesとpnpm workspacesの違いを見ることにする。

特に共通で使っているモジュールをうまくバンドルしてくれるか否かに着目する。

pnpm workspacesを構築していく

pnpmでプロジェクトを作る。

pnpm init

package.jsonが出来上がったら、pnpm以外のパッケージコマンド(npm, yarn)を禁止する設定を入れる。package.jsonと.npmrcファイルに以下のように記述する。

1
{
2
    "name": "pnpm-workspaces",
3
    "version": "1.0.0",
4
    "description": "",
5
    "main": "index.js",
6
    "engines": {
7
        "pnpm": "10.7.1",
8
        "npm": "please_use_pnpm_instead"
9
    },
10
    "scripts": {
11
        "test": "echo \"Error: no test specified\" && exit 1"
12
    },
13
    "keywords": [],
14
    "author": "",
15
    "license": "ISC",
16
    "packageManager": "pnpm@10.7.1"
17
}

1
engine-strict=true

次にworkspaceの設定をする。pnpmの場合はpnpm-workspace.yamlにワークスペースを定義する。

1
packages:
2
  - 'packages/*'

前回と同じくa=ofetch, b=axiosでGitHubのissueを取得する。pnpmにはworkspaceを指定するオプションがないので、-Fで特定のパッケージを絞るコマンドを用意するといろいろ捗る。

1
{
2
    "name": "pnpm-workspaces",
3
    "version": "1.0.0",
4
    "description": "",
5
    "main": "index.js",
6
    "engines": {
7
        "pnpm": "10.7.1",
8
        "npm": "please_use_pnpm_instead"
9
    },
10
    "scripts": {
11
        "test": "echo \"Error: no test specified\" && exit 1",
12
        "a": "pnpm -F \"a\"",
13
        "b": "pnpm -F \"b\""
14
    },
15
    "keywords": [],
16
    "author": "",
17
    "license": "ISC",
18
    "packageManager": "pnpm@10.7.1"
19
}

packageをそれぞれa, bとして用意。

TypeScriptを使えるようにする。

pnpm add typescript
npx tsc --init

ルートのpackage.jsonに入った。

aにofetchを追加してみる。

pnpm a add ofetch

packages/aにnode_modulesが出来上がった。

比べてもこの通り。

引き続きbにaxios、プロジェクト全体にzodを入れて前回の記事と同じ状況を作る。ソースは前と同じものをコピペして持ってきている。

pnpm-workspaces % pnpm b add axios
pnpm-workspaces % pnpm add zod

jsにトランスパイルする。

pnpm-workspaces % tsc

と、各ディレクトリにjsを吐き出してくれた。

中を見てみる。

1
"use strict";
2
var __awaiter = (this && this.__awaiter) || function (thisArg, _arguments, P, generator) {
3
    function adopt(value) { return value instanceof P ? value : new P(function (resolve) { resolve(value); }); }
4
    return new (P || (P = Promise))(function (resolve, reject) {
5
        function fulfilled(value) { try { step(generator.next(value)); } catch (e) { reject(e); } }
6
        function rejected(value) { try { step(generator["throw"](value)); } catch (e) { reject(e); } }
7
        function step(result) { result.done ? resolve(result.value) : adopt(result.value).then(fulfilled, rejected); }
8
        step((generator = generator.apply(thisArg, _arguments || [])).next());
9
    });
10
};
11
Object.defineProperty(exports, "__esModule", { value: true });
12
const ofetch_1 = require("ofetch");
13
const types_1 = require("../types");
14
const fetchIssue = () => __awaiter(void 0, void 0, void 0, function* () {
15
    const url = "https://api.github.com/repos/unjs/citty/issues?state=open";
16
    const data = yield (0, ofetch_1.ofetch)(url, {
17
        method: "GET",
18
        headers: {
19
            Accept: "application/vnd.github.v3+json",
20
        },
21
    });
22
    const issues = data;
23
    console.log("Fetched issues:", issues);
24
    const parsedIssues = issues.map((issue) => (0, types_1.parseGitHubIssueResponse)(issue));
25
    console.log("Parsed issues:", parsedIssues);
26
});
27
fetchIssue();

pnpmの場合、node_modulesはそれぞれのディレクトリにできるのでこれでよい。が、packages以下のディレクトリで結局ルートにinstallしてる依存関係を使うためには結局バンドルしてあげないとダメそう。

ということで、pnpmを使ってもやはりバンドラがないとモノレポとしてうまく機能しなさそうだ。

結論

ワークスペース機能は、ベースとして使いたいパッケージマネージャに依存する
npmでもpnpmでも依存関係を切り分けて管理できることには違いない

tsをjsに吐き出してるのはtsc。だから、パッケージマネージャがそこをいい感じに書き換えたりとかはするわけない。当たり前のことだ。

Copilotに聞いてみたけど`tsconfig`をこねくり回してもダメそうでバンドラを使う方法しか知らなさそう

Post to X

Share to Bluesky

pnpm workspacesでも共通モジュールをうまくバンドラしてくれないのだろうか

前回までのあらすじ

pnpm workspacesを構築していく

結論

Copilotに聞いてみたけどtsconfigをこねくり回してもダメそうでバンドラを使う方法しか知らなさそう

Copilotに聞いてみたけど`tsconfig`をこねくり回してもダメそうでバンドラを使う方法しか知らなさそう