Byside フロントエンド開発環境

Byside のフロントエンド開発環境です。

導入

依存パッケージのインストール：

npm install

ローカルサーバーの起動：

npm run dev

開発用コマンド

npm run dev

ローカルサーバーを起動して、ファイルの変更監視を行います。

npm run build

ビルドしたファイルを ../htdocs ディレクトリに出力します。

ディレクトリ構成

. . ├── develop/ │ ├── /src │ │ ├── assets │ │ │   ├── img │ │ │   │   └─── ページ内で使用している画像 │ │ │   ├── js │ │ │   │   └─── home.js : TOP ページの演出を記述 │ │ │   └── styles │ │ │   ├── privacy.min.scss : TOP ページの scss を記述 │ │ │   ├── thanks.min.scss : TOP ページの scss を記述 │ │ │   ├── home.min.scss : TOP ページの scss を記述 │ │ │   ├── common.min.scss : 全ページ共通で読み込んでいる scss を記述 │ │ │   ├── base │ │ │   │   └── _base.scss : ベースの scss を記述 │ │ │   ├── modules │ │ │   │   └── _component.scss : コンポーネントの scss を記述 │ │ │   └── utils │ │ │   ├── _config.scss : z-index の重なりを設定 │ │ │   ├── _mixins.scss : ブレイクポイントを設定 │ │ │   └── _variables.scss : 変数を設定 │ │ ├── html │ │ │   └── index.pug : TOP ページ │ │ │   └── privacy.pug : プライバシーポリシー │ │ │   └── thanks.pug : お問い合わせ完了ページ │ │ └── template │ │ ├── base │ │ │   ├── head.pug : 共通で読み込む head タグを記述 │ │ │   └── template.pug : 共通で読み込む body を記述 │ │ ├── data │ │ │   └── meta.pug : meta 情報をページ別で記述 │ │ └── layout │ │ │   └── _header.pug : ヘッダー │ ├── conf/ │ ├── node_modules/ │ ├── package.json │ ├── package-lock.json │ ├── README.md │ └── tsconfig.json ├── htdocs : サーバー上でのドキュメントルート └── hookscript.sh : シェルコマンド用ファイル（削除しないでください）

開発ルールについて

クラス命名規則

命名規則は MindBEMding をベースにする。詳細は下記を参照。

• 単語区切りはキャメルケースを採用
• アンダースコア 2 つでエレメント（.block__element）
• エレメントの入れ子は出来るだけ避ける

.blockName__element1__element2 { ... } /* NG */
.blockName__element2 { ... } /* OK */

• ハイフン 2 つでモディファイア（.block__element--modifier）

<div class="card card--wide"></div>

• 状態とバリエーションを区別しない

<div class="blockName -typeLarge -typeBordered -isOpened"></div>

<!-- Better -->
<div class="blockName -large -bordered -opened"></div>

• 単独モディファイアに対しスタイルを宣言しない

.-opened { display: block; } /* NG */
.blockName.-opened { display: block; } /* OK */

SCSS

• &__element の書き方をしない（セレクタとの関係性を表すために & を使うのは問題ない。）
• できるだけブロックごとのファイルを分割を心がける

Git 運用ルール

issue ドリブンを参考にした以下のルールに従って開発してください。

issue ドリブンとは

issue ドリブン開発（課題駆動開発、チケット駆動開発）は、実装における課題をタスクとして管理・運用する開発手法です。

新規機能の追加やバグ修正などを issue として立て、それを解決するためのブランチを切り、コミットやマジリクで適宜 issue を参照しながら開発を進めるというフローを取ります。

参考：https://qiita.com/takahirocook/items/6ac94e5dc6536bd2272c

開発ワークフロー

1. issue の作成

• リポジトリ内の issue タブを押下し、右上の New issue を押下する
• Title に実装における課題を入れる ex) ヘッダー作成
• 必要であれば Discription に、作業の詳細などのメモ書きなどを書く
• Assignee に issue の担当者を入れる
• Label に下記から適宜指定する
  • 機能追加
  • 機能変更
  • 不具合
  • リファクタリング
  • デザイン
  • その他
• Due date は必要であれば設定

1. ブランチの作成

• 新規機能開発用ブランチの場合、以下のブランチ名にする feature/#{issue 番号}{ページ名 or common}内容 例：feature/#1_home_scroll

• バグ修正用ブランチの場合、以下のブランチ名にする fix/#{issue 番号}{ページ名 or common}内容

1. 開発~コミット

• コミットメッセージは以下のフォーマットで行う

{Emoji} {ページ名 or common} {メッセージ} 例：✨ Home 詳細モーダル機能追加

• Emoji は事項を参照

Emoji Prefix

Emoji	コミットタイプ
🎉 :tada:	イニシャルコミット
🐛 :bug:	バグ修正
👍 :+1:	機能改善
✨ :sparkles:	部分的な機能追加
🎨 :art:	デザイン変更のみ
💢 :anger:	コンフリクト
🚧 :construction:	WIP
📝 :memo:	文言修正
♻️ :recycle:	リファクタリング
🔥 :fire:	不要な機能・使われなくなった機能の削除、ファイル削除
💚 :green_heart:	テストや CI の修正・改善
👕 :shirt:	Lint エラーの修正やコードスタイルの修正
🚀 :rocket:	パフォーマンス改善
🆙 :up:	依存パッケージなどのアップデート
👮 :cop:	セキュリティ関連の改善
⚙ :gear:	config 変更
📚 :books:	ドキュメント

1. マージリクエスト作成

• リポジトリ内の Marge Requests タブを押下し、右上の New marge request を押下する
• Source branch にマージしたいブランチを指定し、Target Branch にマージ先のブランチを指定する（基本は develop ブランチになります）
• Title に issue のタイトルを入れる
• Discription に何かコードを見てもらう上で伝えなければいけないことがあれば書く
• Assignee に何かコードを見てもらいたい人を指定する（レビューが必要な場合には）

1. マージ

• マージリクエスト画面から問題がなければ Merge を押下

開発プレビュー用 URL（"https://k627.sjdev.jp/"）への反映方法

1. 作業完了後、develop ブランチに変更分をマージ
2. develop ブランチにて上記 build コマンドで/develop/build/に出力
3. 2.のデータを/htdocs/にコピペする
4. リモートブランチへ push

参孝

• https://necomesi.jp/blog/tsmd/posts/152