プリザンターのjQuery 3→4移行影響を調べてみる[前編：本体コードの影響調査]

Last updated at 2026-03-02Posted at 2026-02-26

はじめに

2025年1月、約9年ぶりとなる jQuery のメジャーバージョンアップ jQuery 4.0.0 がリリースされました。jQuery 3.0 が 2016年6月リリースだったことを考えると、まさに歴史的なアップデートです。

プリザンターでも jQuery は UI の中核として使用されています。将来的に jQuery 4 へ移行するとしたら、一体どのような対応が必要になるのでしょうか。今回はプリザンターのフロントエンドコードを対象に、jQuery 4 への移行影響を調べてみました。

ボリュームがあるため2部構成です。

記事	内容
前編（この記事）	プリザンター本体の JavaScript コードへの影響調査、jQuery Migrate の要否判断
後編	同梱 jQuery プラグインの互換性調査、jQuery Migrate の導入判断、移行の全体方針

バージョン 1.5.1.0 を対象にしています

プリザンターの jQuery 依存状況

まずは現状を把握するところから始めましょう。プリザンターでは jQuery がどのように使われているのかを整理します。

jQuery のバージョン

プリザンターのフロントエンドには2つの jQuery 参照があります。

参照元	バージョン	用途
`plugins/jquery-3.6.0.min.js`	3.6.0	レガシー側（静的ファイル直接参照）
`package.json` の dependencies	3.7.1	PleasanterFrontend（npm + Vite ビルド）

レガシー側の C# コード（HtmlScripts.cs）では jquery-3.6.0.min.js のファイル名がハードコードされています。

Implem.Pleasanter/Libraries/HtmlParts/HtmlScripts.cs

// jQuery 3.6.0 のファイル名がハードコードされている
"assets/plugins/jquery-3.6.0.min.js"

一方、PleasanterFrontend では Vite ビルドにより node_modules の jQuery 3.7.1 が vendor チャンクにバンドルされています。

jQuery プラグイン構成

プリザンターは jQuery 本体以外にも複数の jQuery プラグインを同梱しています。すべて wwwroot/src/plugins/ 配下に格納されています。

プラグイン	バージョン	用途	備考
jQuery UI	v1.13.2	ソート、ドラッグ、タブ、メニューなど
jQuery Validate	v1.21.0	フォームバリデーション
jquery.datetimepicker	不明（xdsoft）	日時ピッカー	v1.4.18.0 で flatpickr に置換済
jQuery File Upload	不明（blueimp）	ファイルアップロード
jQuery MultiSelect	不明（eric hynds）	複数選択 UI
Lightbox	v2.11.4	画像表示
flatpickr	v4.6.13	日時ピッカー（新）	v1.4.18.0 で導入

jquery.datetimepicker は v1.4.18.0（2025年5月のコミット）で flatpickr に置き換えられています。デフォルト設定（UseOldDatepicker = false かつテーマ v2.0 以上）では flatpickr が使用され、旧実装はレガシーフォールバックとして残されている状態です。

プラグインの互換性については後編で詳しく分析します。

スクリプトの構成

フロントエンドのスクリプトは以下のように構成されています。

ディレクトリ	ファイル数	言語	jQuery 依存度
`generals/`	112	JavaScript	高（jQuery ベース）
`generals/modal/`	2	TypeScript	低（`$p.modal` 参照のみ）
`generals/grid-container/`	1	TypeScript	なし（vanilla DOM + Web Component）
`modules/`	15	TypeScript	低（橋渡し程度）

generals/ 配下が jQuery を中心としたレガシーコード、modules/ 配下が vanilla DOM API と Web Components によるモダンなコードという構成になっています。新しく開発される部分は jQuery を直接使わない方針が見て取れます。

jQuery 4.0 の主な破壊的変更

jQuery 4.0 で何が変わったのか、プリザンターに影響しそうなものをピックアップしてみましょう。

削除された非推奨 API

jQuery 3.x まで「非推奨」として残されていた API が、4.0 で完全に削除されました。

削除 API	代替手段
`$.isArray()`	`Array.isArray()`
`$.parseJSON()`	`JSON.parse()`
`$.trim()`	`String.prototype.trim()`
`$.type()`	`typeof` / `instanceof`
`$.now()`	`Date.now()`
`$.isFunction()`	`typeof x === 'function'`
`$.isNumeric()`	自前実装
`$.isWindow()`	自前実装
`$.camelCase()`	自前実装
`$.nodeName()`	`element.nodeName.toLowerCase()`

イベント関連の変更

変更点	影響
`event.which` の shim 削除	jQuery が `keyCode`/`charCode` から自動合成しなくなる
`event.fixHooks` 削除	イベント正規化の低レベル API が廃止
`focusin`/`focusout` 発火順序変更	ネイティブの `focus`/`blur` との順序が変わる

CSS 関連の変更

変更点	影響
`.css()` 数値渡し時の `px` 自動付与ルール変更	`$.cssNumber` リストの変更・削除

AJAX 関連の変更

変更点	影響
`$.ajaxSetup` 非推奨の強化	将来的に削除される可能性
JSONP サポートの削除	`dataType: 'jsonp'` が使えなくなる
Slim ビルドの廃止	通常ビルドのみ提供

その他

変更点	影響
`.bind()` 削除	`.on()` に移行が必要
jQuery プロトタイプの配列メソッド削除	`.push()`/`.sort()`/`.splice()` が jQuery オブジェクトで使えなくなる
`toggleClass(boolean)` 削除	クラス名の指定が必須に

本体コードの影響を調べてみる

では、プリザンターの本体コード（generals/ 配下 112ファイル）に対して、jQuery 4.0 の破壊的変更がどの程度影響するかを見ていきましょう。

削除済み非推奨 API の使用状況

まず安心材料から。jQuery 4.0 で削除される非推奨 API は、プリザンター本体コードでは 一切使用されていません でした。

API	検索結果
`$.isArray`	0件
`$.parseJSON`	0件
`$.trim`	0件
`$.type`	0件
`$.now`	0件
`$.isFunction`	0件
`$.isWindow`	0件
`$.camelCase`	0件
`$.nodeName`	0件
`$.cssNumber` / `$.cssProps`	0件

プリザンター本体のコードは、これらの API をネイティブ JavaScript の標準メソッドで書いており、モダンな書き方に対応済みでした。

高リスク：`event.which` の使用（3箇所）

jQuery 4.0 では event.which の shim（keyCode/charCode からの自動合成）が削除されます。本体コードでは 3箇所で使用されています。

generals/searchevents.js の例を見てみましょう。

Implem.PleasanterFrontend/wwwroot/src/scripts/generals/searchevents.js

// 修正前
if (e.which === 13) {
    // Enter キーで検索実行
}

// 修正後
if (e.key === 'Enter') {
    // Enter キーで検索実行
}

generals/keyevents.js でも同様です。

Implem.PleasanterFrontend/wwwroot/src/scripts/generals/keyevents.js

// 修正前
if (e.which === 13) {
    // Enter キーでフォームのボタン発火
}
return e.which !== 13;

// 修正後
if (e.key === 'Enter') {
    // Enter キーでフォームのボタン発火
}
return e.key !== 'Enter';

修正方針はシンプルで、e.which === 13 を e.key === 'Enter' に置き換えるだけです。

event.keyCode も3箇所で使われていますが、こちらは jQuery ではなくブラウザのネイティブ API です。jQuery 4.0 で jQuery が shim を提供していたのは which のみなので、keyCode は引き続き動作します。ただし event.key への移行が望ましいでしょう。

高リスク：`.css()` 数値渡し（11箇所以上）

jQuery 3.x では .css('top', 100) のように数値を渡すと自動的に "100px" に変換してくれました。jQuery 4.0 ではこの自動変換のルールが変更されるため、明示的に px を付ける必要があります。

z-index のような元々単位を持たないプロパティは安全ですが、top/left/width/height/bottom のような長さプロパティでは注意が必要です。

安全なケース（単位なしプロパティ）

ファイル	コード	リスク
`tenants.js`	`.css('z-index', 110)`	安全
`kamban.js`	`.css('z-index', 2)`	安全
`bulkupdate.js`	`.css('z-index', 110)`	安全

要修正のケース（長さプロパティ）

ファイル	プロパティ	修正方針
`responsive.js`	`bottom`	`parseInt(...) + 'px'`
`viewfilterslabelevents.js`	`top`, `left`	`offset().top + ... + 'px'`
`jqueryui.js`	`top`, `left`	`offset().top + ... + 'px'`
`gridevents.js`	`top`, `left`, `width`, `marginTop`	各値に `+ 'px'`
`gantt.js`	`height`	計算結果に `+ 'px'`

修正例を見てみましょう。

修正前

$('#Menu').css('top', $header.offset().top + $header.outerHeight());
$('#Menu').css('left', $header.offset().left);

修正後

$('#Menu').css('top', $header.offset().top + $header.outerHeight() + 'px');
$('#Menu').css('left', $header.offset().left + 'px');

_dispatch.js では .css(json.Name, json.Value) のようにサーバーサイドから動的にプロパティ名と値を受け取るパターンがあります。サーバーサイドのレスポンスに px 付きの文字列が含まれていれば安全ですが、数値だけの場合はリスクがあります。

中リスク：`$.ajaxSetup` の使用（3箇所）

jQuery 4.0 では $.ajaxSetup の非推奨が強化されています。プリザンターでは CSRF トークンの設定と同期/非同期の切り替えに使用しています。

Implem.PleasanterFrontend/wwwroot/src/scripts/generals/_ajax.js

// CSRF トークン設定
$.ajaxSetup({
    beforeSend: function (xhr) {
        xhr.setRequestHeader('RequestVerificationToken', token);
    }
});

Implem.PleasanterFrontend/wwwroot/src/scripts/generals/_api.js

// 同期/非同期切替
$.ajaxSetup({ async: args.async });

将来的には個別の $.ajax オプションに移行することが推奨されます。

中リスク：`.bind()` の使用（1箇所）

.bind() は jQuery 3.x で非推奨化され、4.0 で削除される可能性があります。

Implem.PleasanterFrontend/wwwroot/src/scripts/generals/confirmevents.js

// 修正前
$(window).bind('beforeunload', function () { ... });

// 修正後
$(window).on('beforeunload', function () { ... });

低リスク：影響が限定的なもの

対象	箇所数	影響
`focusin` イベント順序変更	1	動作確認のみでOK
`event.keyCode` 使用	3	jQuery 4.0 でも動作する
`$(document).ajaxComplete()`	1	動作確認のみでOK

影響なしの領域

modules/ 配下の TypeScript ファイルは、主に vanilla DOM API と Web Components で構成されており、jQuery の使用は $p.set($(element), value) や $p.display() などプリザンター独自グローバル API への橋渡しに限定されています。jQuery 4.0 の破壊的変更に該当するパターンは検出されませんでした。

影響度サマリー

本体コードの影響を改修優先度別に整理します。

高リスク（動作が壊れる可能性が高い）

対象	ファイル数	箇所数	改修内容
`event.which` 使用	2	3	`event.key === 'Enter'` に置換
`.css()` 数値渡し	5	11+	数値に `+ 'px'` を付与

中リスク（将来の削除に備えて）

対象	ファイル数	箇所数	改修内容
`$.ajaxSetup` 使用	2	3	個別の `$.ajax` オプションに移行
`.bind()` 使用	1	1	`.on()` に置換
`$.ajaxSettings.xhr()` 参照	1	1	標準の `XMLHttpRequest` を使用
`async: false`（同期 AJAX）	1	1	`Promise` ベースの非同期処理に移行

低リスク（動作確認のみ）

対象	ファイル数	箇所数	改修内容
`focusin` イベント順序変更	1	1	テストで確認
`event.keyCode` 使用	3	3	`event.key` への移行を推奨
`$(document).ajaxComplete()`	1	1	テストで確認

jQuery Migrate は本体コードに必要か？

ここで重要な判断ポイントです。jQuery Migrate プラグインを導入すれば、削除された API のポリフィルが提供されるため、コードを修正しなくても動作させることができます。

しかし、本体コードに関しては jQuery Migrate は不要 というのが結論です。理由は以下の通りです。

削除済み非推奨 API の使用がゼロ — jQuery Migrate が提供するポリフィルの大部分が不要
高リスク箇所の改修が容易 — event.which は3箇所、.css() 数値渡しは11箇所で、いずれも機械的な置換で対応可能
Migrate 自体がオーバーヘッド — 不要なポリフィルコードを読み込むことになる

ただし、プラグインについてはまた話が変わってきます。後編で詳しく見ていきましょう。

サーバーサイドでの変更点

JavaScript ファイルの修正だけでは不十分です。C# のコードにも手を入れる必要があります。