Parcelを使いこなす！設定不要バンドラーのベストプラクティス集 ✨

Parcelの最大の魅力は設定不要である点です。まずはこの恩恵を最大限に受けましょう。簡単なプロジェクトやプロトタイピングでは、設定ファイルを一切作成せずに開発を始めることができます。

基本的な使い方

Parcelをインストールしたら（通常はプロジェクトの`devDependencies`として）、HTMLファイルを指定して実行するだけです。

# プロジェクトにParcelをインストール
npm install --save-dev parcel
# または
yarn add --dev parcel

# 開発サーバーを起動 (例: src/index.html をエントリーポイントとする)
npx parcel src/index.html

これだけで、Parcelは`src/index.html`を解析し、そこからリンクされているCSS、JavaScript、画像などの依存関係を自動で見つけ出し、開発サーバーを立ち上げてくれます。ブラウザで指定されたURL（通常は http://localhost:1234）を開けば、開発中のアプリケーションが表示されます。

{
  "scripts": {
    "dev": "parcel src/index.html",
    "build": "parcel build src/index.html"
  }
}

複雑な設定が必要になるまでは、このゼロコンフィグのアプローチを維持しましょう。設定ファイルがないことで、プロジェクトの見通しが良くなり、他の開発者も理解しやすくなります。

`parcel serve` (または単に `parcel`) コマンドで起動する開発サーバーは非常に高機能です。特にホットリロード (HMR) は開発効率を大幅に向上させます。

ホットリロード (HMR) とは？

コード（JavaScript、CSSなど）を変更すると、Parcelは変更されたモジュールだけを検出し、ブラウザをリロードすることなく、実行中のアプリケーションにその変更を適用します。これにより、アプリケーションの状態を維持したまま、変更結果を即座に確認できます。特に、UIコンポーネントの開発やデバッグ時に威力を発揮します。

Parcelは、特別な設定なしで多くのフレームワーク（React、Vueなど）のHMRをサポートしています。もしカスタムセットアップが必要な場合でも、Parcelが提供するHMR APIを利用できますが、ほとんどの場合は自動で機能します。

HTTPSでの開発

Service Workerや特定のWeb APIを利用する場合など、HTTPS環境で開発を行いたい場合があります。Parcelでは、簡単なオプションでHTTPSサーバーを起動できます。

npx parcel src/index.html --https

初回起動時には、自己署名証明書が自動生成されます。ブラウザで警告が表示される場合がありますが、開発目的であれば許可して進めることができます。

開発サーバーの機能をフル活用し、快適な開発体験を実現しましょう。

開発が完了したら、本番環境向けの最適化されたファイルを生成する必要があります。これには `parcel build` コマンドを使用します。

npx parcel build src/index.html

このコマンドを実行すると、Parcelはデフォルトで以下のような最適化を行います。

これらの最適化は、特別な設定なしに自動で行われます。生成されたファイル（デフォルトでは `dist` ディレクトリに出力されます）をサーバーにデプロイすれば、最適化されたアプリケーションを公開できます。

Parcelは、生成するコードがどのブラウザやNode.jsのバージョンで動作する必要があるかを知るために、targets 設定を参照します。これは非常に重要な設定であり、適切に設定することで、不要なPolyfillやトランスパイルを避け、最適なコードを生成できます。

`targets` は、`package.json` ファイルに記述するか、独立した `.browserslistrc` ファイルに記述します (Browserslist の構文を使用)。

`package.json` での設定例:

{
  "name": "my-parcel-project",
  "version": "1.0.0",
  "targets": {
    "modern_browsers": {
      "engines": {
        "browsers": [
          "> 0.5%",
          "last 2 versions",
          "Firefox ESR",
          "not dead"
        ]
      }
    },
    "legacy_browsers": {
      "engines": {
        "browsers": [
          "ie 11"
        ]
      },
      // IE11向けには module/nomodule パターンを使わない場合など
      "outputFormat": "global"
    }
  },
  "devDependencies": {
    "parcel": "^2.x.x"
  }
}

上記の例では、`modern_browsers` と `legacy_browsers` という2つのターゲットを定義しています。Parcel はビルド時にこれらのターゲットに応じたコードを生成します。

ベストプラクティスとしては、プロジェクトがサポートすべき最も古い環境を `targets` で明示的に指定することです。 これにより、Parcel は必要な互換性処理（例えば、古いJavaScript構文への変換やPolyfillの追加）を正確に行うことができます。指定しない場合、Parcel はデフォルトのターゲット（比較的モダンなブラウザ）を使用しますが、プロジェクトの要件と合致しない可能性があります。

ターゲット設定は、生成されるコードのサイズとパフォーマンスに直接影響します。サポート範囲を広くするほど、多くのPolyfillが含まれ、バンドルサイズが大きくなる傾向があります。プロジェクトの要件に合わせて、適切なバランスを見つけましょう。

詳細については、Parcel 公式ドキュメントの Targets のセクション を参照してください。

モダンCSSを書く上で、ベンダープレフィックス（`-webkit-`, `-moz-` など）の管理は面倒な作業です。Parcelは PostCSS と Autoprefixer を自動で統合しており、この問題を解決してくれます。

Autoprefixer は、前述の `targets` 設定（または `.browserslistrc`）に基づいて、必要なベンダープレフィックスをCSSに自動で追加してくれます。

設定方法

特別な設定は不要です！ Parcelはプロジェクト内に PostCSS の設定ファイル (`.postcssrc`, `postcss.config.js` など) が存在しない場合、自動的に Autoprefixer を有効にします。必要なのは、`package.json` または `.browserslistrc` で `targets` (Browserslist) を設定することだけです。

// package.json の例
{
  "browserslist": [
    "> 1%",
    "last 2 versions",
    "not dead"
  ]
}

これにより、例えば以下のようなCSSを書いた場合：

.example {
  display: grid;
  user-select: none;
}

Parcelはビルド時に、指定したターゲットブラウザに必要なプレフィックスを付与します。

/* targets の設定によっては以下のように変換される */
.example {
  display: grid;
  -webkit-user-select: none;
     -moz-user-select: none;
      -ms-user-select: none;
          user-select: none;
}

もし、Autoprefixer 以外の PostCSS プラグイン（例: `postcss-nested`, `tailwindcss`）を使いたい場合は、プロジェクトルートに PostCSS の設定ファイルを作成します。Parcel はその設定ファイルを自動で読み込み、適用します。その際、Autoprefixer も含めるかどうかは設定ファイル次第になります。

// postcss.config.js の例 (Tailwind CSS を使う場合)
module.exports = {
  plugins: {
    tailwindcss: {},
    autoprefixer: {}, // Autoprefixerも使う場合は明示的に記述
  },
}

基本的には Parcel の自動適用に任せ、より高度なカスタマイズが必要な場合にのみ設定ファイルを作成するのが良いでしょう。

Parcelは、JavaScriptだけでなく、TypeScript、JSX (React)、Vue シングルファイルコンポーネントなども、特別な設定なしで扱うことができます。

TypeScript

`.ts` または `.tsx` ファイルをプロジェクトに追加し、それをHTMLや他のJavaScript/TypeScriptファイルからインポートするだけで、Parcelは自動的にTypeScriptコンパイラ (tsc) を使ってトランスパイルします。`tsconfig.json` がプロジェクトルートにあれば、その設定が尊重されます。なければ、Parcelは適切なデフォルト設定を使用します。

// src/index.ts
import { greet } from './utils';

const message: string = greet('Parcel User');
console.log(message);

document.getElementById('app')!.textContent = message;

<!-- src/index.html -->
<!DOCTYPE html>
<html>
<head>
  <title>Parcel with TypeScript</title>
</head>
<body>
  <div id="app"></div>
  <script type="module" src="index.ts"></script>
</body>
</html>

上記のように記述し `npx parcel src/index.html` を実行すれば、TypeScriptが適切に処理されます。

React (JSX)

ReactとJSXを使用する場合も同様です。Reactライブラリをインストールし、`.jsx` または `.tsx` ファイルを使用すれば、Parcelは自動でJSXをトランスパイルします。

npm install react react-dom
# または
yarn add react react-dom

// src/App.jsx
import React from 'react';

function App() {
  return <h1>Hello from React! 👋</h1>;
}

export default App;

// src/index.jsx
import React from 'react';
import { createRoot } from 'react-dom/client';
import App from './App';

const container = document.getElementById('app');
const root = createRoot(container);
root.render(<App />);

<!-- src/index.html -->
<!DOCTYPE html>
<html>
<head>
  <title>Parcel with React</title>
</head>
<body>
  <div id="app"></div>
  <script type="module" src="index.jsx"></script>
</body>
</html>

Vue

Vueのシングルファイルコンポーネント (`.vue` ファイル) もサポートされています。`vue` ライブラリをインストールし、`.vue` ファイルを作成してインポートするだけです。

npm install vue
# または
yarn add vue

<!-- src/App.vue -->
<template>
  <h1>{{ message }}</h1>
</template>

<script>
export default {
  data() {
    return {
      message: 'Hello from Vue! 💚'
    }
  }
}
</script>

<style scoped>
h1 {
  color: green;
}
</style>

// src/index.js
import { createApp } from 'vue';
import App from './App.vue';

createApp(App).mount('#app');

<!-- src/index.html -->
<!DOCTYPE html>
<html>
<head>
  <title>Parcel with Vue</title>
</head>
<body>
  <div id="app"></div>
  <script type="module" src="index.js"></script>
</body>
</html>

このように、Parcelは主要なフロントエンド技術スタックを簡単に導入できるように設計されています。

アプリケーション開発では、APIキーや環境固有の設定値など、コードに直接埋め込みたくない情報を扱う必要があります。Parcelは .env ファイルを使った環境変数の管理を標準でサポートしています。

`.env` ファイルの利用

プロジェクトルートに `.env` ファイルを作成し、キーと値のペアを記述します。

# .env
API_KEY=your_secret_api_key
API_ENDPOINT=https://api.example.com/v1
NODE_ENV=development

これらの変数は、JavaScriptコード内で `process.env.変数名` としてアクセスできます。

// src/api.js
const apiKey = process.env.API_KEY;
const apiEndpoint = process.env.API_ENDPOINT;

console.log(`Using API Endpoint: ${apiEndpoint}`);
// 注意: APIキーをクライアントサイドのコードにそのまま埋め込むのはセキュリティリスクがあります。
// バックエンド経由で利用するか、サーバーサイドレンダリング時にのみ利用するなど検討してください。
// console.log(`API Key: ${apiKey}`);

環境ごとの `.env` ファイル

Parcelは、`NODE_ENV` 環境変数（開発時は `development`、本番ビルド時は `production` がデフォルト）に応じて、異なる `.env` ファイルを読み込むことができます。

• `.env.development`: 開発時にのみ読み込まれる
• `.env.production`: 本番ビルド時にのみ読み込まれる
• `.env.local`: すべての環境で読み込まれるが、`.git` には含めないローカル固有の設定用（`.env` より優先）
• `.env.development.local`: 開発時のローカル固有設定（`.env.development` より優先）
• `.env.production.local`: 本番ビルド時のローカル固有設定（`.env.production` より優先）

この仕組みを利用して、開発環境と本番環境で異なるAPIエンドポイントや設定値を使用できます。

# .env.development
API_ENDPOINT=https://dev.api.example.com/v1

# .env.production
API_ENDPOINT=https://api.example.com/v1

環境変数を適切に管理することで、設定の切り替えが容易になり、セキュリティも向上します。

Parcelは、JavaScriptやCSSだけでなく、画像、フォント、WebAssemblyなど、さまざまな種類のアセットを扱うことができます。

アセットのインポート

HTML、CSS、JavaScriptファイルから、相対パスや絶対パス（プロジェクトルートからの）、あるいはNodeモジュール解決の仕組みを使ってアセットをインポート（参照）できます。

<!-- HTMLでの画像参照 -->
<img src="./images/logo.png" alt="Logo">

<!-- HTMLでのCSS参照 -->
<link rel="stylesheet" href="./styles/main.css">

<!-- HTMLでのJS参照 -->
<script type="module" src="./app.js"></script>

/* CSSでの画像参照 */
.hero {
  background-image: url('../images/background.jpg');
}

/* CSSでのフォント参照 */
@font-face {
  font-family: 'MyCustomFont';
  src: url('../fonts/myfont.woff2') format('woff2');
}

// JavaScriptでの画像インポート
import logoUrl from './images/logo.png';

const imgElement = document.createElement('img');
imgElement.src = logoUrl;
document.body.appendChild(imgElement);

// JavaScriptでのCSSインポート (CSS Modulesも利用可能)
import './styles/main.css';

// JavaScriptでのWorkerインポート
const worker = new Worker(new URL('./worker.js', import.meta.url));
worker.postMessage('Hello from main thread!');

パス解決とURL依存関係

Parcelはこれらの参照を検出し、依存関係グラフに含めます。ビルド時には、アセットを適切に処理（コピー、最適化、バンドルなど）し、出力ディレクトリ (`dist`) に配置します。そして、参照元のコード内のパスを、最終的に出力されたファイルのURLに自動的に書き換えます。

これにより、開発者はファイルが最終的にどこに配置されるかを意識することなく、ソースファイルからの相対パスなどで直感的にアセットを参照できます。

アプリケーションが大きくなるにつれて、JavaScriptバンドルのサイズも増加し、初期ロード時間が長くなる可能性があります。Parcelはコード分割 (Code Splitting) を用いてこの問題を解決します。

自動コード分割

Parcelは、以下の条件で自動的にコードを別々のバンドルに分割します。

• 複数のエントリーポイント間で共有されているモジュール。
• 動的インポート (`import()`) を使用している箇所。

特に動的インポートは、初期ロード時に必要ないコードを遅延読み込みさせるための強力な手法です。

// main.js (初期ロードされるコード)
async function loadHeavyComponent() {
  // ボタンがクリックされた時など、必要なタイミングでモジュールを読み込む
  const module = await import('./heavyComponent');
  const HeavyComponent = module.default;
  // コンポーネントをレンダリングするなどの処理
  HeavyComponent.render();
}

document.getElementById('loadButton').addEventListener('click', loadHeavyComponent);

// heavyComponent.js (初期ロード時には読み込まれない)
console.log('Heavy component loaded!');

export default {
  render() {
    // 重い処理や大きなライブラリを含むコンポーネントの描画など
    document.getElementById('app').innerHTML = '<h2>Heavy Component Rendered!</h2>';
  }
};

上記の例では、`heavyComponent.js` とその依存関係は、`loadHeavyComponent` 関数が実行される（つまり、`import()` が呼び出される）まで読み込まれません。Parcelはビルド時に `heavyComponent.js` を別のファイル（例: `heavyComponent.abcdef12.js`）として出力し、`main.js` がそれを非同期で読み込めるようにコードを生成します。

コード分割の利点

• 初期ロード時間の短縮: 最初に必要なコードだけを読み込むため、ページの表示が速くなります。
• オンデマンド読み込み: ユーザーが特定の機能を使用するときに初めて関連コードを読み込むため、リソースを効率的に利用できます。
• キャッシュ効率の向上: コードが複数のチャンクに分割されるため、一部のコードが変更されても、他のチャンクはキャッシュから利用できます。

ルートベースのコード分割（各ページコンポーネントを動的インポートする）や、特定の機能（例: モーダルダイアログ、高機能エディタ）を動的インポートするなど、アプリケーションの構造に合わせて効果的にコード分割を活用しましょう。

Parcelは、ビルド時間を短縮するために強力なキャッシュ機構を備えています。一度ビルドしたファイルや計算結果をキャッシュしておき、次回以降のビルドでは変更があった部分のみを再処理します。これにより、特に大規模なプロジェクトでの再ビルド時間を大幅に削減できます。

キャッシュの場所

キャッシュファイルは、デフォルトでプロジェクトルートの `.parcel-cache` ディレクトリに保存されます。このディレクトリは `.gitignore` に追加しておくのが一般的です。

キャッシュのクリア

通常、キャッシュは自動で管理され、開発者が意識する必要はありません。しかし、稀にキャッシュが原因で予期せぬ問題（古いコードが使われる、ビルドエラーが解消しないなど）が発生することがあります。

そのような場合は、キャッシュを一度クリアしてみると問題が解決することがあります。

rm -rf .parcel-cache

キャッシュを削除した後、再度 `parcel` や `parcel build` を実行すると、すべてのファイルが再処理されるため時間はかかりますが、クリーンな状態でビルドが行われます。

Parcelのキャッシュは非常に効果的ですが、その存在と、問題発生時の対処法（キャッシュクリア）を知っておくことが重要です。

Parcelはゼロコンフィグを目指していますが、より高度なカスタマイズや、標準ではサポートされていない機能を追加したい場合には、プラグインを利用できます。Parcel 2では、プラグインシステムが刷新され、より柔軟な拡張が可能になりました。

プラグインには、特定のファイルタイプを処理するTransformer、ビルド結果をレポートするReporter、依存関係解決をカスタマイズするResolverなど、様々な種類があります。

プラグインの例

• @parcel/transformer-yaml: YAMLファイルをJavaScriptオブジェクトとしてインポートできるようにする。
• parcel-reporter-bundle-analyzer: ビルド後のバンドルサイズの内訳を視覚的に表示するレポートを生成する。
• @parcel/validator-eslint: ESLintによるコード検証をビルドプロセスに組み込む（デフォルトで有効な場合あり）。

プラグインの導入方法

プラグインは通常、npm/yarnでインストールし、プロジェクトルートに `.parcelrc` という設定ファイルを作成して記述します。

npm install --save-dev parcel-reporter-bundle-analyzer
# または
yarn add --dev parcel-reporter-bundle-analyzer

// .parcelrc
{
  "extends": "@parcel/config-default",
  "reporters": ["...", "parcel-reporter-bundle-analyzer"]
}

`”extends”: “@parcel/config-default”` は、Parcelのデフォルト設定を継承することを意味します。`”…”` は、デフォルトで設定されているリポーターを省略せずに含めるための記述です。

プラグイン導入の注意点

ベストプラクティスとしては、プラグインの導入は必要最小限に留めることです。 プラグインを追加すると、Parcelの「設定不要」というメリットが薄れ、設定が複雑になる可能性があります。また、プラグインの品質やメンテナンス状況によっては、予期せぬ問題を引き起こす可能性もあります。

まずはParcelの標準機能で要件を満たせないか十分に検討し、それでも必要な場合にのみ、信頼できるプラグインを選択して導入するようにしましょう。

開発中にエラーはつきものです。Parcelは、エラー発生時に分かりやすい情報を提供しようと努めています。

エラーメッセージ

ビルドエラーやランタイムエラーが発生すると、Parcelはコンソールに詳細なエラーメッセージを出力します。多くの場合、エラーが発生したファイル名、行番号、そしてエラーの原因を示すコードスニペットが表示されます。

🚨 Build failed.

@ C:\path\to\project\src\index.js:5:1
  4 | const message = "Hello Parcel";
> 5 | console.log(message; // Missing closing parenthesis
    | ^ SyntaxError: Unexpected token ';'. Expected ')' to end an argument list.
  6 |

エラーメッセージをよく読み、どのファイルのどの部分で問題が発生しているかを特定しましょう。Parcelのエラーメッセージは比較的親切なので、問題解決の大きな手がかりになります。

ソースマップ

Parcelは開発ビルド（`parcel serve`）ではデフォルトでソースマップを有効にします。ソースマップは、バンドル・トランスパイルされたコード（ブラウザが実際に実行するコード）と、元のソースコード（あなたが書いたコード）を関連付けるファイルです。

これにより、ブラウザの開発者ツールでデバッグを行う際に、元のソースコード（例: TypeScriptやJSXファイル）上でブレークポイントを設定したり、エラーが発生した箇所を確認したりできます。これはデバッグ効率を大幅に向上させるため、非常に重要です。

本番ビルド（`parcel build`）では、デフォルトでソースマップは生成されませんが、必要に応じて有効にすることも可能です（ただし、ソースコードが公開されるリスクがあるため注意が必要です）。

# 本番ビルドでソースマップを生成する
npx parcel build src/index.html --no-optimize --source-maps

エラーメッセージとソースマップを活用し、効率的にデバッグを進めましょう。