Skip to content

MS_WebEssentials

Jump to bottom
nishi_74322014 edited this page Aug 21, 2026 · 1 revision

Web Essentials

概要

Microsoft の（正確には Microsoft のプログラムマネージャーである Mads Kristensen 氏を
中心としたコミュニティが開発・主導した）Visual Studio 向け拡張機能

  • Visual Studio 拡張の一つ。2010 年にリリース。

  • 一般的な Web 開発を行う上で役に立つ機能を実装している。

    • HTML / CSS / JavaScript
    • TypeScript / CoffeeScript / LESS 等

  • 機能が継続的に追加されている。

補足（Mads Kristensen 氏について）: 本ページが名前を挙げている通り、
Web Essentials は個人（＋コミュニティ）主導という性格が強い。

【この出自が意味すること】
   ・Microsoft の【公式製品ではない】
      → サポート契約の対象外
      → VS のバージョンアップで動かなくなることがある
   ・その代わり【身軽で、実験的な機能を先に出せる】★
      → 良い機能は VS 本体に取り込まれる、という流れが生まれた

**「拡張機能で試し、定着したら本体に入れる」**という
Visual Studio の機能拡充のやり方を、
Web Essentials は体現していた。
本ページの「変遷」節が、まさにその過程の記録である。

詳細

変遷

「Web Essentials」は、時代ごとのフロントエンド技術のトレンドや、
Visual Studio 本体の進化に合わせてその役割を大きく変えてきた。

黎明期

Visual Studio 2010 〜 2013（単一の超強力プラグイン時代）

  • 2010 年頃に初版がリリースされた「Web Essentials」は、
    当時の Visual Studio に不足していた最新の Web 標準や
    フロントエンド開発環境を補完する「実験場」として機能
  • オールインワンの機能追加：HTML5、CSS3、JavaScript の高度なインテリセンス（入力補完）や、
    色のプレビュー、画像の DataURI 変換などを 1 つの拡張機能で提供。
  • 新言語の早期サポート：当時登場したばかりの LESS、Sass、CoffeeScript、
    そして TypeScript のコンパイル機能や、
    ファイルの軽量化（Minify）、結合（Bundling）機能をいち早く搭載

補足（当時の Visual Studio に何が欠けていたか）: 「実験場として機能」
という表現の背景を補っておく。

【2010 年頃の Visual Studio】
   ・【サーバ側の開発ツール】としては非常に強力
      C#、ASP.NET Web Forms、デバッガ、デザイナ
   ・【クライアント側】は貧弱
      JavaScript は「補完が効かないテキスト」に近い扱い
      CSS3 のプロパティを知らない
      LESS/Sass？ そんなものは知らない

【なぜそうだったか】
   ASP.NET Web Forms は【サーバがすべての HTML を生成する】前提
     → 開発者が JS/CSS を直接書く量が少なかった
     → [ASP.NET Web Forms] / [部分描画とJavaScript] 参照

しかし 2010 年前後にフロントエンドが急速に高度化した。

jQuery の普及 → Ajax が当たり前に
HTML5 / CSS3 の策定
Node.js の登場（2009）
CoffeeScript（2009）、LESS（2009）、Sass の普及
TypeScript の発表（2012）★

VS 本体の開発サイクル（3 年）では追随できない——
だから拡張機能が「実験場」として必要だった、という構図である。

転換期

Web Extension Pack for Visual Studio 2015（肥大化の解消と機能の「解体・分割」）

  • Web Essentials 2015 の時代に入ると、1 つの拡張機能に機能を詰め込みすぎたことで、
    動作の重さやメンテナンス性の低下が問題視されるようになる。
    また、Node.js ベースのビルドツール（Gulp や Grunt）が台頭。
  • コンパイラの削除：LESS や Sass などのコンパイル機能が本体から削除され、
    外部のタスクランナー（Gulp 等）へ処理を委ねる方針にシフト。
  • 機能のマイクロ拡張化（Web Extension Pack）：Web Essentials を
    単一のプラグインとして提供するのをやめ、機能ごとにバラバラの小さな拡張機能
    （「Bundler & Minifier」「Web Compiler」など）として分割
  • それらを一括でインストールするためのメタ・パッケージ（福袋のようなもの）として、
    一時期「Web Extension Pack」という名称に変更された。

補足（この転換が示すもの）: 「コンパイラの削除」という判断は、
本ページで最も重要な出来事である。

【何が起きたのか】

 【前】 IDE がビルドの面倒を全部見る
     Visual Studio
       └ Web Essentials が LESS/Sass/TS をコンパイル
       → 【VS がないとビルドできない】★
       → CI サーバに VS を入れる必要がある
       → Mac/Linux の開発者は参加できない

 【後】 ビルドは Node.js のツールチェーンに任せる
     package.json（gulpfile.js / webpack.config.js）
       └ どの環境でも npm run build で同じ結果
       → 【IDE 非依存】＝ VS でも VS Code でも Vim でもよい
       → CI が単純になる

これは ASP.NET の BundleConfig が
廃れたのと同じ流れである。

【同じ構図の 3 つの出来事】
   ① Web Essentials のコンパイラ削除（2015）
   ② BundleConfig → Vite/webpack（ASP.NET Core）
   ③ JavaScript Services の廃止（2019）
        → [JavaScript Services] 参照

 すべて「【.NET 側がフロントの面倒を見るのをやめる】」という
 同じ方向を向いている ★

移行メモ（Gulp / Grunt の現況）: 本節が台頭したと記録している
Gulp と Grunt は、現在はほぼ使われていない。

【タスク ランナーの変遷】
   Grunt（2012）… 設定ファイル方式。冗長で廃れた
   Gulp（2013） … ストリーム方式。一時期主流
   npm scripts  … 【package.json に書くだけ】★ 現在の標準
   webpack/Vite … バンドラがタスクも兼ねるようになった

// 現在は package.json の scripts で足りることが多い
{ "scripts": {
    "dev": "vite",
    "build": "tsc && vite build",
    "lint": "eslint src --ext .ts,.tsx",
    "format": "prettier --write src"
}}

再構築

Visual Studio 2017 〜 2019（ブランドの復活と本体への統合）

  • ユーザーからのフィードバックを受け、再びお馴染みの「Web Essentials」の
    ブランディングが復活（Web Essentials 2017 / 2019）。
  • パッケージとしての定着：中身は VS 2015 時代と同様に
    「便利な単機能の拡張機能を集めた拡張機能パック」という構造のまま、
    名称が「Web Essentials」に戻る。
  • Visual Studio 本体への吸収：Web Essentials が先んじて実装した機能の多くが、
    Visual Studio 自体の標準機能として正式に組み込まれた。

成熟・現在

Visual Studio 2022 以降（役割の終焉とレガシー化）

  • 近年の Visual Studio 2022 以降の開発環境においては、
    Web Essentials の存在感はかつてほど絶対的なものではなくなっています。
  • VS 本体の進化: 現在では、Visual Studio 本体の Web 開発ツール
    （エディタ機能、JavaScript/TypeScript サポート）が非常に強力になり、
    かつて Web Essentials を入れなければ実現できなかったことの大半が、
    デフォルトで動作するようになっています。
  • VS Code へのシフト：主戦場が VS Code へと移行したこともあり、
    大規模な機能追加などの激しい変遷は落ち着き、
    現在は役割を終えた、あるいは成熟したツールとして扱われている。

補足（拡張機能が「役割を終える」のは成功である）: 本節の
「役割の終焉とレガシー化」という総括は正確だが、
これは失敗ではなく、拡張機能としての成功である。

【拡張機能の理想的な一生】
   ① 本体にない機能を提供する
   ② 使われて、需要が証明される
   ③ 【本体に取り込まれる】★
   ④ 拡張機能としては不要になる

 → Web Essentials は ③④ に到達した

VS 本体に取り込まれた主な機能:

かつて Web Essentials が提供 現在
HTML5 / CSS3 の補完 VS 本体の標準機能
JavaScript / TypeScript の高度な補完 本体（TypeScript 言語サービス）
CSS の色プレビュー 本体
画像の DataURI 変換 本体 / 不要（ビルド ツールが行う）
Sass / LESS のコンパイル ビルド ツール（Vite/webpack）へ
Bundle & Minify ビルド ツールへ
ブラウザー リンク 本体（ただし現在は縮小）

現在、Visual Studio でフロントエンド開発をする場合:

・拡張機能は【ほぼ不要】
・[.esproj（JavaScript・TypeScriptプロジェクトシステム）] で
  npm ベースのプロジェクトを VS のソリューションに載せられる ★
・ただし、【フロント作業自体は VS Code の方が快適】というのが実情

Mads Kristensen 氏は現在も VS 拡張を多数公開している
（Markdown Editor、File Icons、Add New File など）。
Web Essentials という「束」ではなく、
個別の小さな拡張として提供する形に落ち着いた。

分割機能

Excelsior Compiler / Web Compiler

  • Web Essentials / Web Compiler の後継
  • Sass (SCSS) や Less のコンパイル、Minify（圧縮）を VS 上で行うための拡張機能

Npm Task Runner / Command Line Execution

  • NPM / パッケージ管理サポート
  • package.json に書かれたスクリプト（npm run dev や build）を、
    VS の「タスク ランナー エクスプローラー」から GUI で直接実行・管理

JavaScript/TypeScript Linting

  • コードの品質管理（Linter）
  • ESLint や Prettier の設定を検知し、VS のエディタ上にリアルタイムで
    エラーや警告を表示

補足（現在これらをどう扱うか）: 分割された 3 系統は、
現在は「拡張機能ではなく、プロジェクトの設定」で実現する。

① CSS のコンパイル

【拡張機能に頼らない方法】
   npm install -D sass
   package.json に "build:css": "sass src/scss:dist/css" を書く

 → VS でも VS Code でも CI でも同じように動く ★
 → Vite を使っているなら、【設定なしで .scss を import できる】

// Vite なら、これだけで Sass が通る（sass を devDependencies に入れるだけ）
import './styles/main.scss';

② npm スクリプトの実行

・VS 2022 は【タスク ランナー エクスプローラーを標準搭載】
・VS Code は【npm スクリプト ビューを標準搭載】
  → 拡張機能は不要になった

③ Lint / Format

【現在の標準構成】
   ESLint    … 【コードの誤り・危険なパターン】を検出
   Prettier  … 【整形】（改行位置、引用符、セミコロン）
     → 役割が違うので【両方入れる】のが定石

   ※ 近年は Biome（Rust 製。Lint + Format を 1 つで、高速）も有力

// package.json に入れて、【エディタに依存させない】
{ "scripts": {
    "lint": "eslint . --max-warnings 0",
    "format:check": "prettier --check ."
}}

重要なのは「エディタの設定に依存させない」ことである。

✗ 「VS に拡張を入れた人だけ整形される」
    → 人によって整形が違い、【差分が汚れる】★

○ ・設定ファイル（.eslintrc / .prettierrc）をリポジトリに入れる
   ・package.json のスクリプトから実行できるようにする
   ・【CI で検査する】（lint に失敗したらマージさせない）
   ・エディタの拡張は「早く気付くための補助」に過ぎない

.editorconfig も併用すると、
エディタを問わず基本的な整形（インデント、改行コード、文字コード）が揃う。
Visual Studio も VS Code も標準で対応している。

# .editorconfig
root = true
[*]
charset = utf-8
end_of_line = lf
insert_final_newline = true
indent_style = space
indent_size = 2

[*.cs]
indent_size = 4

**改行コード（end_of_line）**は、
Windows と Linux/macOS が混在するチームで問題になりやすい
（Git の core.autocrlf と併せて方針を決める）。

参考

miso_soup3 Blog

Webサイト作成の迷い道

CodeZine（コードジン）

THE TRUTH IS OUT THERE

Microsoft Learn

Tags: 移行, .NET開発, ASP.NET, ASP.NET Web API, ASP.NET SPA, JavaScript

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally