Zenn
🧵

【Laravel】SCSS×Vite 導入方法

に公開
Laravel
Sass
Scss
frontend
Vite
tech

はじめに

style.cssのどこに何を書いたか分からず、修正のたびに時間がかかり、競合が起こりスタイルが反映されない…。そんなCSSの課題に直面していませんか？

本記事では、CSSファイルの肥大化や競合の問題をViteを用いたSCSS（Sass）の導入でどのように解消できるかを解説します。

本記事の対象者

  • CSSファイルが肥大化し悩んでいるエンジニア
  • スタイルの競合に困っている方
  • style.css に直接スタイルを書いており、Viteなどのビルド環境に不安がある方

前提知識

そもそも「Sass（サス）」とは？

「サス」というと、SCSS（サス）や Sass（サス）のように複数思い浮かべる方もいるかもしれません。
これらの違いについては、どちらもSassの一部です。

SCSS（Sassy CSS）とSass（Syntactically Awesome Style Sheets）は、どちらも「Sass（サス）」というCSSメタ言語の記法の種類です。つまり、どちらもSassに含まれるスタイル記法であり、Sassという言語に対する2つの書き方だと考えると分かりやすいです。

これらのファイルは、ビルドツールなどを用いてコンパイルすることで、通常の .css ファイルに変換され、ブラウザで読み込める形式になります。

拡張子 記法 特徴
.scss CSSに近い構文 セミコロン（;）や波括弧（{}）を使用し、既存のCSSと互換性が高い。現在はこちらが主流です
.sass インデントベース構文 {}や;を使わず、Pythonのようにインデントで階層を表現。より簡潔な記述が可能

SassとScssの文法の違い（例）

Sassの構文（インデントベース）
Sass（インデント記法）は記述が非常に簡潔ですが、CSSの書き方と大きく異なるため、初学者にはやや分かりづらいという声がありました。

ul.red
  margin: 2em 0

  li.tl
    text-align: left

SCSSの構文（CSSライク）
CSSとほぼ同じ構文で書けるSCSS記法が後から登場し、現在は実務・学習のいずれにおいてもSCSSの方が主流となっています。
SCSSでは通常のCSSと同様の書き方が可能で、CSSの知識がそのまま活用できるため、学習コストが低く、読みやすさ・保守性の面でもメリットが大きいです。

ul.red {
  margin: 2em 0;

  li.tl {
    text-align: left;
  }
}

SCSS×Vite 環境構築手順

  1. プロジェクト初期化（未導入の場合）
    ※ 対話を省略してすぐにVanillaテンプレートを選ぶ場合
npm create vite@latest my-app -- --template vanilla
cd my-app
npm install
  1. Sassのインストール
npm install -D sass
  1. SCSSファイル作成・インポート

SCSSをビルド対象とするには、JavaScript側のエントリーポイント（例：resources/js/app.js）にて以下のように明示的に読み込みます

app.js
import '../scss/app.scss';

LaravelにおけるSCSSの配置場所とおすすめ構成

Laravelでは、SCSSファイルは resources ディレクトリ内に配置するのが推奨される方法です。一例ですが、具体的には以下のような構成を取ることで、保守性と拡張性を高めることができます。

resources/
└── scss/
    ├── app.scss            // メインエントリポイント
    ├── foundation/         // 変数定義、リセットCSSなど
    │   ├── _variables.scss
    │   └── _reset.scss
    ├── layout/             // ヘッダー、フッターなど全体構造
    │   ├── _header.scss
    │   └── _footer.scss
    ├── components/         // ボタン、フォームなどのUI部品
    │   ├── _button.scss
    │   └── _form.scss
    └── pages/              // ページ単位のスタイル（必要に応じて）
        ├── _home.scss
        └── _about.scss

各ファイルは先頭に _ をつけることで、SCSS側の @use や @import 時に個別出力されない「パーシャルファイル」として管理されます。

このように、責務ごとに明確にディレクトリを分けることで、大規模アプリケーションにおいてもスタイルの管理が容易になります。

なお、ファイル名に _ をつけなくても @import や @use による読み込みは可能ですが、一般的に「パーシャルファイル（部分的なモジュール）」を意味するために _ を使う慣習があります。

また、SCSSではディレクトリを @import 'foundation'; のようにフォルダ名だけで一括読み込みすることはできません。そのため、必要なファイルを個別に指定して読み込む必要があります。

例：

style.scss
@import 'foundation/variables';
@import 'foundation/reset';

ViteでSCSSをビルドするための設定例

vite.config.js でグローバルに SCSS 変数などを読み込みたい場合は、以下のように記述します。
この設定により、すべてのSCSSファイルで共通の変数やmixinを読み込むことが可能になります。

vite.config.js
import { defineConfig } from 'vite';
import laravel from 'laravel-vite-plugin';

export default defineConfig({
  plugins: [
    laravel({
      input: ['resources/scss/app.scss', 'resources/js/app.js'],
      refresh: true,
    }),
  ],
  css: {
    preprocessorOptions: {
      scss: {
        additionalData: `@use "@/scss/foundation/variables" as *;`
      }
    }
  }
});

SCSSのメリット5選

1. ネスト構造でHTML構造と直感的に連携できる

.card-title の命名文脈が明確になり、保守性が上がります。

.card {
  &-title {
    font-size: 1.2rem;
    color: #333;
  }
}

2. 変数による統一管理で色やサイズ変更も一括反映

色変更が1ヶ所で済むため、変更コストが大幅削減されます。

$primary-color: #007acc;
body {
  color: $primary-color;
}

3. ファイル分割と @import による構造化

各モジュールの責務を分離し、読みやすく整理できます。

// style.scss
@import 'reset';
@import 'components/card';

4. @mixin / @extend でDRY原則を実現

共通処理を一元化し、記述の重複を削減します。

@mixin clearfix() {
  &::after {
    content: "";
    display: block;
    clear: both;
  }
}
.container {
  @include clearfix();
}

5. 命名競合・セレクタ衝突の回避

命名の衝突やセレクタ競合を回避し、意図しないスタイル崩れを防止します。

.admin-form {
  input {
    border-color: red;
  }
}

Tips

SCSSの注意点

  • 即時反映しない：Viteなどのビルド環境ではSCSSの変更がリアルタイムに反映されないことも。常駐型コマンドである npm run dev でHMR（ホットモジュールリプレース）を活用するとコードの変更を即座にブラウザに反映できます。
  • 過度なネスト構造：3階層以上のネストは読みにくくなるため、構造の深さに注意してください。
  • 独自構文の理解が必要：初めは構文が馴染みにくいですが、VSCodeのSCSS補完拡張でカバーできるのでおすすめです。

@use / @forward への移行とモダンなSCSS管理の注意点

従来は @import によってSCSSファイルを読み込んでいましたが、現在は公式に 非推奨 となっており、代わりに @use / @forward を使うことが推奨されています。

主な違いとメリット

  • @import は同じファイルを複数回読み込んでしまう可能性がある（冗長）
  • @use は一度だけ読み込まれ、名前空間が自動的に付与されるため競合を避けやすい
  • @forward はモジュールファイル内から他のファイルを「再エクスポート」するための仕組み

例：foundation/_index.scss

@forward 'variables';
@forward 'reset';

使用側（app.scss）

@use 'foundation/index' as *;

このように @forward で集約し、@use 側では名前空間付きや省略形で管理することで、より大規模なSCSS設計に適した構成になります。

おわりに

SCSSの導入によって、CSSの肥大化、命名競合、構造の曖昧さといった課題を段階的に解消できます。

私自身、style.cssを1ファイルで管理していた頃は、修正のたびに競合があり時間がかかっていました。いまではSCSSによって、構造化されたスタイルとなりUIの修正作業がとても楽になりました。

CSSの管理に悩んでいる方こそ、SCSS導入をぜひ一度試してみてください。
本記事が、あなたのCSS設計の参考になれば幸いです。

株式会社ONE WEDGE

【Serverlessで世の中をもっと楽しく】
ONE WEDGEはServerlessシステム開発を中核技術としてWeb系システム開発、AWS/GCPを利用した業務システム・サービス開発、PWAを用いたモバイル開発、Alexaスキル開発など、元気と技術力を武器にお客様に真摯に向き合う価値創造企業です。
https://onewedge.co.jp/

GitHubで編集を提案

Discussion