経緯
Github Actions
難読化
- Terserやってみた
- webpackのmode(development/production)
デプロイ対象を限定する
所要時間

経緯

前回、 TypeScript と Jest と Webpack で簡単な1アプリを作った
- t-hazawa.hatenablog.com
今回、それを Github Actions で CI/CD (commit の push があったら自動でテストして通ったら自動でGithub Pagesにデプロイ)、 Webpackによる難読化、Github Pages での公開範囲をちゃんと狭めるをした
その結果、結構モダンになった

Github Actions

そのものずばり、やり方を ChatGPT(GPT-4) に聞いた

私は、github.com上にリポジトリをもっていて、それをgithub pagesで公開しています。
このリポジトリでgithub actions を使いたいです。
github actionsでやりたいことは

    commit の pushしたら、
　　自動でtest走って (jestのテストがあります)
　　通ったら自動でデプロイ(github pagesに)

です。どうすればできますか？
ー

GitHub Actionsを使用して、コミットがプッシュされた際に自動でテストを実行し、テストが通ったらGitHub Pagesに自動でデプロイするワークフローを設定するには、以下のステップを実行します。

### 1. GitHub Actionsのワークフローファイルを作成

1. リポジトリのルートに `.github/workflows` ディレクトリを作成します。
2. そのディレクトリ内にワークフローファイルを作成します（例：`deploy.yml`）。

### 2. ワークフローファイルの内容を定義

以下は`deploy.yml`ファイルの例です。このワークフローは、`main`ブランチへのプッシュ時にトリガーされ、Node.jsをセットアップし、依存関係をインストールした後、Jestでテストを実行し、テストが成功した場合にのみGitHub Pagesへデプロイします。

name: Deploy to GitHub Pages

on:
  push:
    branches:
      - main  # デプロイをトリガーするブランチ

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v2

    - name: Set up Node.js
      uses: actions/setup-node@v1
      with:
        node-version: '14' # 使用するNode.jsのバージョン

    - name: Install dependencies
      run: npm install

    - name: Run tests
      run: npm test # Jestなどのテストコマンド

    - name: Deploy to GitHub Pages
      if: success() # テストが成功した場合にのみ実行
      uses: peaceiris/actions-gh-pages@v3
      with:
        github_token: ${{ secrets.GITHUB_TOKEN }}
        publish_dir: ./public # デプロイするディレクトリ


### 3. テストコマンドの設定

`package.json`ファイルにテストスクリプトを設定しておきます。Jestを使用している場合、以下のように設定することが多いです。

"scripts": {
  "test": "jest"
}


### 4. GitHub Pagesの設定

GitHubリポジトリのSettingsタブに移動し、"Pages"セクションを見つけて、GitHub Pagesのソースとしてデプロイされるブランチやディレクトリ（例えば`gh-pages`ブランチまたは`docs`フォルダ）を設定します。`peaceiris/actions-gh-pages`アクションは、デフォルトで`gh-pages`ブランチにデプロイします。

### まとめ

これで、`main`ブランチへのプッシュがあるたびに自動でJestテストが実行され、テストが成功した場合のみGitHub Pagesへの自動デプロイが行われるようになります。GitHub Actionsは非常に柔軟なため、さらに複雑なワークフローや条件を設定することも可能です。

Github Actions の入門記事を読んだ
- qiita.com
大事そう & 便利そう ↓

最初のステップでは、外部で定義された別のアクションを呼び出しています。このステップではactions/checkout@v3つまり、自分自身のレポジトリのデータを読み込む、という処理が走っています。このステップから始まるワークフローが一番多いと思われます。（こういった外部呼び出しされるアクションはGitHubで公開されています→actions/checkout）

なんかデプロイできなかった
↓は関係なかった (Githubのマシン用一時トークン)

        github_token: ${{ secrets.GITHUB_TOKEN }}
の意味を教えてください
ー
`github_token: ${{ secrets.GITHUB_TOKEN }}`の記述は、GitHub Actionsのワークフローファイル内で使用され、GitHubが提供する自動生成されたトークンにアクセスするための構文です。このトークンは、ワークフローが実行される際にGitHubによって自動的に作成され、リポジトリ内での様々な操作を認証するために使用されます。

### GitHubトークンの役割

- **認証と権限**: `GITHUB_TOKEN`は、GitHub APIへの認証とリポジトリ内の特定のアクション（例えば、コミットのプッシュ、プルリクエストの作成、GitHub Pagesへのデプロイなど）を実行する権限をGitHub Actionsに与えます。
- **セキュリティ**: このトークンはワークフローが実行されるたびに自動的に生成され、ワークフローの実行後に期限切れになります。これにより、長期間有効なパーソナルアクセストークンをリポジトリに保存するリスクを避けることができます。
- **簡単な設定**: ユーザーが手動でトークンを生成し、GitHubのシークレットに保存する必要はありません。`GITHUB_TOKEN`はGitHubによって自動的に提供され、使用するための追加の設定は必要ありません。

### 使用例

`GITHUB_TOKEN`は、GitHub Actionsのワークフロー内で次のようにして使用されます。

steps:
  - name: Some Step
    uses: some-action/some-repo@v1
    with:
      github_token: ${{ secrets.GITHUB_TOKEN }}


この例では、`some-action/some-repo@v1`というアクションが実行される際に`GITHUB_TOKEN`が渡されます。このトークンを使用することで、アクションはGitHub APIへの認証済みのリクエストを行い、リポジトリに対して権限のある操作を実行できます。

### 注意点

- `GITHUB_TOKEN`はGitHub Actionsの実行中にのみ有効であり、ワークフロー外での使用はできません。
- デフォルトの権限では足りない場合、リポジトリの設定からGitHub Actionsに対する`GITHUB_TOKEN`の権限を調整することができます。

↓の1.だった (リポジトリのGithub Actions向けパーミッション設定)(デフォルトはReadだけで、Writeも許可するには設定変更が必要)

下のようなエラーが出ました。どうすればいいですか？


5s
Run peaceiris/actions-gh-pages@v3
[INFO] Usage https://github.com/peaceiris/actions-gh-pages#readme
Dump inputs
Setup auth token
Prepare publishing assets
Setup Git config
Create a commit
Push the commit or tag
  /usr/bin/git push origin gh-pages
  remote: Permission to Who/What.git denied to github-actions[bot].
  fatal: unable to access 'https://github.com/Who/What.git/': The requested URL returned error: 403
  Error: Action failed with "The process '/usr/bin/git' failed with exit code 128"
ー

エラーメッセージには、「github-actions[bot]」が「Who/What.git」リポジトリに対して十分な権限を持っていないため、`gh-pages`ブランチに対してコミットをプッシュできなかったことが示されています。この問題を解決するために、以下のステップを試してみてください。

### 1. リポジトリの設定を確認する

- GitHubリポジトリの設定にアクセスし、`Settings` > `Actions` > `General`に移動して、`Workflow permissions`のセクションを確認します。
- `Read and write permissions`が選択されていることを確認してください。これにより、GitHub Actionsがリポジトリに対して変更をプッシュできるようになります。

### 2. GitHub Pagesの設定を確認する

- リポジトリの`Settings` > `Pages`セクションに移動し、GitHub Pagesの設定が正しく設定されていることを確認してください。特に、デプロイされるブランチが`gh-pages`であることを確認します。

### 3. Personal Access Token (PAT)の使用を検討する

GitHub Actionsのデフォルトの`GITHUB_TOKEN`が権限不足の場合、より広範な権限を持つPersonal Access Token (PAT)を生成して使用することができます。

1. GitHubで自分のアカウント設定に移動し、「Developer settings」 > 「Personal access tokens」にアクセスします。
2. 「Generate new token」をクリックし、必要な権限を選択してトークンを生成します。`repo`スコープが必要です。
3. 生成されたトークンをコピーし、リポジトリの`Settings` > `Secrets`に移動して新しいシークレットを作成します。シークレット名を例えば`PERSONAL_ACCESS_TOKEN`とし、値にトークンをペーストします。
4. ワークフローファイルを編集し、`secrets.GITHUB_TOKEN`の代わりに新しく作成したシークレット（`secrets.PERSONAL_ACCESS_TOKEN`）を使用します。

with:
  github_token: ${{ secrets.PERSONAL_ACCESS_TOKEN }}


### 注意

Personal Access Tokenを使用する場合は、トークンの権限が広範囲に及ぶため、セキュリティリスクを最小限に抑えるために注意して管理する必要があります。

これらのステップに従っても問題が解決しない場合、GitHubのドキュメントやコミュニティフォーラムでさらにサポートを求めることも検討してください。

疑問

jestのsuccess ってどれだけが基準？　2024/04/11 23:16

ーー
  - name: Run tests
      run: npm test 
    - name: Deploy to GitHub Pages
      if: success() 
って、どれだけテストがPASSしたら success()が真になるのですか？

ー

GitHub Actionsの`if: success()`条件は、それまでのステップで実行されたコマンドがすべて成功した場合に真（true）になります。具体的には、前のステップの実行結果が正常終了（exit code 0）であることが要求されます。

### テストの成功基準

- **Jestなどのテストフレームワークの場合**：テストスクリプトがエラーなしに完了し、すべてのテストがPASS（通過）することが求められます。一つでもテストがFAIL（失敗）すると、Jestは非ゼロの終了コードを返し、これがGitHub Actionsによってエラーとして認識されます。

### 実用的な例

例えば、以下のようにGitHub Actionsのワークフローが設定されている場合：

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v2

    - name: Set up Node.js
      uses: actions/setup-node@v1
      with:
        node-version: '14'

    - name: Install dependencies
      run: npm install

    - name: Run tests
      run: npm test # ここでJestが全てのテストを実行

    - name: Deploy to GitHub Pages
      if: success() # テストが全て成功した場合にのみ実行
      uses: peaceiris/actions-gh-pages@v3
      with:
        github_token: ${{ secrets.GITHUB_TOKEN }}
        publish_dir: ./build


この設定において:

1. `npm test`コマンドが実行され、全てのJestテストがパスすると、このステップは正常終了（exit code 0）を返します。
2. `if: success()`条件は、`npm test`の結果が成功であったかどうかを評価します。成功の場合、次の「Deploy to GitHub Pages」ステップが実行されます。
3. 一つでもテストが失敗し、非ゼロの終了コードが返された場合、`if: success()`はfalseと評価され、デプロイのステップはスキップされます。

このように、`success()`は直前のステップの成功を基準にしており、テストステップが全てのテストケースでPASSすることが必須条件となります。

↑ 書いたテスト全部がPASS(というかFAILしない)が success の条件だった

難読化

私はTypescript でコードを書いてます。
webpack を使っています。
難読化したいです。

ー
TypeScriptでコードを書いているプロジェクトにWebpackを使用しており、コードの難読化を望んでいる場合、Webpackプラグインを利用してこのプロセスを自動化することができます。特にJavaScriptの難読化には、`uglifyjs-webpack-plugin` や `terser-webpack-plugin` がよく使用されます。ここでは、それらの設定方法について説明します。

### 1. Terser Webpack Plugin

`terser-webpack-plugin` は、ES6+ をサポートしており、デフォルトのWebpackのminimizerとしても使われています。このプラグインを使うと、コードの圧縮と難読化を行うことができます。

#### インストール

まずは、プラグインをインストールします。

npm install terser-webpack-plugin --save-dev

#### Webpack設定

次に、`webpack.config.js` ファイルを編集して、Terser Pluginを設定します。

const TerserPlugin = require('terser-webpack-plugin');

module.exports = {
  mode: 'production',
  optimization: {
    minimize: true,
    minimizer: [new TerserPlugin({
      terserOptions: {
        compress: {
          drop_console: true, // コンソールログを削除
        },
        mangle: true, // 変数名を短縮、置換する
      },
    })],
  },
  // 他の設定...
};


この設定では、`compress` オプションでコンソールログを削除し、`mangle` オプションで変数名を変更しています。これにより、コードの読みやすさが低下し、難読化されます。

### 2. Uglifyjs Webpack Plugin（非推奨）

`uglifyjs-webpack-plugin` は古いプラグインであり、ES6以上のJavaScriptには対応していません。もしES5以下のコードを扱っている場合には使用することができますが、最新のプロジェクトでは`terser-webpack-plugin`の使用が推奨されます。

### 注意点

- **デバッグ**: 難読化されたコードはデバッグが困難になります。そのため、本番環境専用に設定し、開発環境では難読化を適用しないことをお勧めします。
- **ライセンスと著作権**: コードの難読化がライセンス違反にならないように、使用しているライブラリやフレームワークのライセンスを確認してください。

これらのステップでWebpackを使用したTypeScriptプロジェクトのコード難読化を行うことができます。各オプションの詳細や追加設定については、各プラグインのドキュメントを参照してください。

Terserやってみた


npm install terser-webpack-plugin --save-dev

PS > npm install terser-webpack-plugin --save-dev

changed 28 packages, and audited 440 packages in 12s

43 packages are looking for funding
  run `npm fund` for details

found 0 vulnerabilities

普通にはいった

webpackのmode(development/production)

webpack の mode の development と production ってなんですか？
ー
Webpackの`mode`オプションは、Webpackがビルドをどのように扱うかを定義する重要な設定の一つです。`mode`は`development`、`production`、`none`の三つの設定値の中から選べますが、一般的には`development`と`production`が最も頻繁に使用されます。それぞれのモードは特定の用途に最適化されており、ビルドのパフォーマンス、出力されるコードの最適化の度合いなどに影響を与えます。

### Development Mode (`development`)

- **目的**: 開発プロセスを迅速かつ効率的にすること。
- **特徴**:
  - ソースマップを生成し、デバッグを容易にする。
  - ビルド時間の短縮に重点を置いているため、最小化や最適化は行われない。
  - ファイルの変更を監視して自動的に再コンパイルする（Hot Module Replacementなど）。
  
使用例:
module.exports = {
  mode: 'development',
  // その他の設定...
};


### Production Mode (`production`)

- **目的**: 本番環境用にコードを準備すること。これには、パフォーマンスの最適化とセキュリティの向上が含まれる。
- **特徴**:
  - コードを圧縮（minify）してファイルサイズを減らす。
  - 不要なコードやデバッグコードを削除（tree shakingなど）。
  - パフォーマンス最適化のための機能が自動的に有効化される。
  - セキュリティを強化するために、より少ない情報を公開する。

使用例:
module.exports = {
  mode: 'production',
  // その他の設定...
};


### None Mode (`none`)

- 明示的にどのようなデフォルトの最適化も適用しないように設定します。`none`モードでは、開発者がすべての最適化を手動で制御することになります。

### 選択基準

- **開発中**：迅速なビルドと詳細なデバッグ情報が必要なため、`development`モードを使用します。
- **本番環境へのデプロイ前**：パフォーマンスとセキュリティが最優先されるため、`production`モードを使用して、コードを最適化し、余分なものを削除します。

Webpackの`mode`設定を適切に使い分けることで、開発の効率と本番環境でのアプリケーションのパフォーマンスを最大化することができます

Hot Module Replacement を教えて
ー
Hot Module Replacement（HMR）は、ウェブアプリケーション開発の際に特に有用な機能で、Webpackをはじめとするモダンなビルドツールでサポートされています。HMRは、アプリケーションが実行中に、更新されたモジュール（JavaScript、CSSなど）をリロードすることなく交換することを可能にします。これにより、アプリケーションの状態を保持したまま、コードの変更が即座に反映されるため、開発プロセスが大幅に高速化されます。

### HMRの主な利点：

1. **即時のフィードバック**：ファイルを保存するとすぐに変更がブラウザに反映されるため、変更を確認するための待ち時間がほとんどなくなります。
2. **状態の保持**：通常のページリロードでは失われる可能性のあるアプリケーションの状態（たとえば、ユーザーの入力や現在のナビゲーション状態）を保持しながら、コードの更新を行えます。
3. **リソースの節約**：フルページリロードではなく、変更されたモジュールのみが交換されるため、リソースの消費を抑えることができます。

### HMRのセットアップ方法：

WebpackでHMRを設定するには、いくつかのステップが必要です。以下に基本的な設定の例を示します。

1. **Webpackの設定**：
   ```javascript
   const webpack = require('webpack');
   const path = require('path');

   module.exports = {
     entry: [
       'webpack/hot/dev-server',  // HMRのためのWebpackデベロッパーサーバー
       'webpack-hot-middleware/client', // HMRのためのミドルウェアクライアント
       './src/index.js' // あなたのエントリーポイント
     ],
     output: {
       path: path.resolve(__dirname, 'dist'),
       filename: 'bundle.js'
     },
     module: {
       rules: [/* ローダーの設定など */]
     },
     plugins: [
       new webpack.HotModuleReplacementPlugin() // HMRプラグインを有効にする
     ]
   };
   ```
2. **開発サーバーの設定**：
   通常、`webpack-dev-server` を使用しますが、HMRを有効にするオプションを付ける必要があります。
   ```bash
   webpack serve --hot --mode development
   ```

3. **コード内でのHMR APIの利用**：
   HMRを活用するためには、アプリケーションのコード内でHMR APIを適切に扱う必要があります。例えば、Reactアプリケーションでの利用方法は以下のようになります。
   ```javascript
   if (module.hot) {
     module.hot.accept('./App', () => {
       const NextApp = require('./App').default;
       render(NextApp);
     });
   }
   ```

HMRは開発効率を大幅に向上させる強力なツールですが、プロダクション環境では無効にすることが一般的です。また、すべてのタイプの変更がHMRで適切に扱えるわけではないため、場合によっては手動でのリフレッシュが必要なこともあります。

tree shaking って何？
ー

Tree shakingは、モダンなJavaScriptビルドツールで使われる一般的な最適化手法で、不要なコードを最終的なアプリケーションバンドルから削除することを目的としています。この技術は、アプリケーションのパフォーマンスを向上させ、ロード時間を短縮するのに役立ちます。

### どのように機能するか？

Tree shakingの基本的なアイデアは、使用されていないモジュール（コードの断片）を「振り落とす（shake off）」ことです。多くの現代的なJavaScriptプロジェクトは、多数のライブラリやフレームワークに依存しており、これらの全てのコードが実際には使用されているわけではありません。Tree shakingを行うことで、これら未使用のコード部分を自動的に識別し、最終的なバンドルから除去することができます。

### どのようなツールで利用されているか？

Tree shakingは、WebpackやRollupのようなモジュールバンドラーで一般的にサポートされています。これらのツールは、ES6モジュール（`import`と`export`構文を使用）の静的な構造を解析して、どのモジュールが実際に使用されているかを特定します。その後、使用されていないモジュールを最終的な出力から除外します。

### Tree Shakingの実装方法

Webpackなどを使用している場合、Tree shakingを有効にするには以下のステップが含まれます：

1. **ES6モジュール構文の使用**: Tree shakingはES6の`import`および`export`構文を使ったモジュールでのみ機能します。CommonJSの`require()`や`module.exports`では効果的に機能しません。

2. **プロダクションモードの有効化**: 例えばWebpackを使用する場合、`mode: 'production'`を設定ファイルに指定します。これにより、未使用コードの除去や他の最適化が自動的に行われます。

3. **サイドエフェクトの管理**: `package.json`に`"sideEffects": false`を設定することで、プロジェクト内のモジュールが副作用を持たないことをビルドツールに伝え、より積極的な最適化を可能にします。

### 注意点

- **サイドエフェクト**: 一部のモジュールやライブラリは、単にインポートされること自体によって副作用（例えば、ポリフィルの追加やグローバルスコープの変更）をもたらします。これらの副作用を持つモジュールは、Tree shakingによって誤って削除される可能性があります。
- **設定の正確性**: Tree shakingが効果的に機能するためには、ビルドツールの設定が正確である必要があります。不適切な設定は、予期しないバグを導入するリスクを増加させることがあります。

Tree shakingは、大規模なフロントエンドプロジェクトのパフォーマンス最適化において非常に重要な技術です。適切に使用すれば、アプリケーションの効

webpack.config.js の mode が development だと、変数名が元のままだったり、あんまり難読化されてなかったが、 mode を production にしたら、しっかり難読化がなされた

提供された3つのWebpack設定スニペットは、主に`mode`設定で異なりますが、これにより生成されるコードにもいくつかの違いが出てきます。ここで重要なのは、`mode`の設定が`production`と`development`でどのように異なる影響を与えるかです。

### 1. `mode: 'production'`

- **最適化**: `production`モードはデフォルトで多くの最適化が有効になっています。これには、モジュールの連結（Scope Hoisting）、より小さな出力ファイルサイズ、より効率的なランタイムコードが含まれます。
- **デバッグ**: ソースマップはデフォルトでは簡略化されており、デバッグは少し難しくなりますが、パフォーマンスと最適化に焦点を当てています。

### 2. `mode: 'development'`

- **デバッグ向け**: `development`モードは、デバッグを容易にするための設定がデフォルトで有効になっています。これには、詳細なエラーメッセージや未処理のモジュール名が含まれます。
- **パフォーマンス**: このモードでは最適化は少なく、生成されるバンドルはより大きくなりがちです。また、ホットモジュールリプレースメント（HMR）などの開発便利機能がサポートされています。

### 3. `minimize: true`と`minimizer`の影響

すべての設定例で、`minimize: true`および`TerserPlugin`が有効化されています。これにより、`development`モードでもコードは圧縮され、変数名は短縮され、コンソールログが削除されます。これは通常、`production`モードで期待される動作ですが、`development`モードでこれらのオプションを使うと、ビルドプロセスが遅くなる可能性があり、デバッグが困難になることがあります。

### 結論

- **`production`モードの設定**: 最適化が進んでおり、サイズが小さく、実行効率が高いコードが生成されますが、デバッグが難しくなります。
- **`development`モードの設定**: 開発者向けの機能が充実しており、デバッグが容易ですが、最適化は少なく、ビルドサイズが大きくなります。ただし、明示的に`minimize`と`TerserPlugin`を使用しているため、一部の`production`向けの最適化（圧縮や難読化）が行われます。

一般的に、開発中は`development`モードを、本番環境のビルドには`production`モードを使用するのが最適です。それぞれのモードが提供するデフォルトの設定を理解し、プロジェクトのニーズに合わせて適切に設定することが重要です。

webpack.config.js の mode を production と development で使い分けるのはどうするの？
1つの webpack.config.js ファイルに mode: 'production' の設定と mode: 'development'の設定を書くの？　それとも、 webpack.config.js ファイルを2つ用意するの？　それとも、buildしたいモードを毎回 webpack.config.js に書くの？

ー
Webpackの設定で`mode`を`production`と`development`で使い分ける方法はいくつかあります。最も一般的なアプローチは、単一の`webpack.config.js`ファイル内で条件を設定する方法、コマンドライン引数を使用する方法、そして設定ファイルを複数用意する方法です。それぞれのアプローチについて説明します。

### 1. 単一の`webpack.config.js`ファイルで条件を設定する

一つの設定ファイル内で`NODE_ENV`環境変数を使用して、`mode`を動的に設定することができます。以下はその例です：

const isProduction = process.env.NODE_ENV === 'production';

module.exports = {
  mode: isProduction ? 'production' : 'development',
  // その他の設定...
  optimization: {
    minimize: isProduction // 本番環境のみ最小化を有効にする
  },
  devtool: isProduction ? 'source-map' : 'eval-source-map',
  // 詳細な設定...
};


### 2. コマンドライン引数を使用する

`webpack`コマンドを実行する際に、`--mode`オプションを指定して直接モードを設定することも可能です。これを行うには、package.jsonのscriptsセクションに以下のように記述します：

"scripts": {
  "build": "webpack --mode production",
  "dev": "webpack serve --mode development"
}


この設定により、`npm run build`を実行すると本番モードでビルドが行われ、`npm run dev`で開発サーバーが開発モードで起動します。

### 3. 複数の設定ファイルを用意する

異なる設定が大幅に異なる場合は、`webpack.config.js`を分割して、例えば`webpack.config.dev.js`と`webpack.config.prod.js`という形で別々のファイルを用意する方法もあります。それぞれのファイルで異なる設定を行い、コマンドラインから適切な設定ファイルを指定してビルドします。

"scripts": {
  "build": "webpack --config webpack.config.prod.js",
  "dev": "webpack serve --config webpack.config.dev.js"
}


### おすすめの方法

一般的には、設定の差が少ない場合は環境変数を使用した単一の設定ファイルを用いる方法が推奨されます。これにより、設定の重複を避けることができ、管理が簡単になります。しかし、設定が大幅に異なる大規模なプロジェクトでは、設定ファイルを分割する方法がクリアで管理しやすい場合があります。

このように、プロジェクトのニーズや設定の複雑さに応じて、最適な方法を選択してください。

デプロイ対象を限定する

node_modules/ とか src/ を公開したくない、ということ
自動化の github Actions の workflow/ の方の設定ファイルの公開対象ディレクトリ指定も変える必要があった

現在、 github pages へのデプロイを gh-pages -d . でやっています。
しかし、これでは、 ./にある node_modules/ など、本来公開する必要のないディレクトリまで公開されてしまいます。

公開したいものだけを公開するには、 ./ の下に public/ ディレクトリを作り、そこに公開したいものを置けばいいのですね？
ー
はい、その通りです。GitHub Pagesで公開したいコンテンツのみを特定のディレクトリ（たとえば`public/`）に配置し、そのディレクトリを指定してデプロイすることは一般的なアプローチです。これにより、不要なファイルやディレクトリ（例えば`node_modules/`）がWebに公開されるのを避けることができます。

以下は、`gh-pages`コマンドを使って特定のディレクトリからGitHub Pagesにデプロイする方法です。

### ステップ 1: `public/`ディレクトリを作成

プロジェクトのルートディレクトリ内に`public/`ディレクトリを作成し、その中に公開したいファイルを配置します。HTML、CSS、JavaScriptファイルなど、Webサイトで必要なリソースをすべてこのディレクトリに入れます。

### ステップ 2: `gh-pages`を使ってデプロイ

`gh-pages`コマンドを使用して、`public/`ディレクトリの内容をGitHub Pagesにデプロイします。コマンドは次のようになります：

gh-pages -d public

このコマンドは、`public/`ディレクトリ内のファイルをGitHubの`gh-pages`ブランチにプッシュします。GitHub Pagesはこのブランチをチェックし、そこにある内容をWebサイトとして公開します。

### 注意点

- **.gitignore**: `public/`ディレクトリがGitリポジトリの`.gitignore`ファイルに含まれていないことを確認してください。デプロイしたいコンテンツがGitに追跡されていないと、`gh-pages`はそれをデプロイできません。
- **ビルドスクリプト**: プロジェクトがビルドプロセスを必要とする場合（たとえばReactアプリケーションなど）、ビルドスクリプトが`public/`ディレクトリ内に最終的な成果物を出力するように設定してください。
- **セキュリティ**: 公開するファイルには機密情報が含まれていないことを確認してください。

このアプローチを取ることで、サイトの公開範囲を正確にコントロールし、不要または機密性の高い情報が誤って公開されることを防ぐことができます。

所要時間

6日間でモダンにし終わった (2時間)
この記事(17500文字)は 1日強(30分) で書けた

t_hazawaの日記

株式投資とWebエンジニアリングのブログです。株式投資の目次は→です。 https://t-hazawa.hatenablog.com/entry/2021/02/12/220933

Github ActionsとWebpackによる難読化とGithub Pagesで必要なものだけ公開するのをやった

経緯

Github Actions

難読化

Terserやってみた

webpackのmode(development/production)

デプロイ対象を限定する

所要時間