Web Storage API で発生しうる例外（DOMException）を ESLint で検証する

投稿

Web Storage API はその使い方やユーザー環境によって例外が発生し得ます。

例えば以下のように 5MB を超えるデータを setItem() しようとすると QuotaExceededError が発生します。

try {
	const storageKey = 'foo';

	sessionStorage.clear();
	sessionStorage.setItem(storageKey, 'x'.repeat(5242880 - storageKey.length + 1)); // 5MB を超えるデータをセット
} catch (e) {
	if (e instanceof DOMException) {
		console.warn(e.name); // `QuotaExceededError`（ただし Cookie がブロックされている場合は `SecurityError`） 
	}
}

ブラウザの設定で Cookie をブロックしている場合はプロパティやメソッドを呼び出さずとも常に SecurityError が発生します。

try {
	sessionStorage;
} catch (e) {
	if (e instanceof DOMException) {
		console.warn(e.name); // `SecurityError`
	}
}

これらのことは Web storage API の仕様書(WHATWG)に書かれているのはもちろん、MDN の解説でも触れられているのですが、どういうわけか世の中には sessionStorage や localStorage を try...catch で囲っていない、怖いもの知らずなコードがそれなりに存在するのです。 

const foo = sessionStorage.getItem('foo');

doSomething(); // ブラウザの設定で Cookie をブロックしている場合、この関数は実行されない

実際のサイトで散見され始めたのは2018年頃で、当時 Web Storage API を使う際は Cookie 無効環境も考慮しようという記事を書いたのですが、その後は某著名フレームワークの普及もあってレイアウトが崩れる（CSS が部分的にしか適用されない）どころか情報がまったく閲覧できないサイトが増加してしまいました。

そのような流れに対して、いずれ ESLint などに検証ルールが追加されるだろうと静観していたのですが、一向にその気配がありません。似た思想を持つプラグインとして eslint-plugin-try-catch-failsafe(GitHub) があるのですが、これは JSON.parse() と new URL() のみが対象であり、Storage のルールは存在しません。

  • URL は canParse() メソッド(developer.mozilla.org)が実用可能になってきているので、try...catch で囲わなければならないケースは今後減るでしょう。

ということで今さらではあるのですが、さくっとプラグインを作ってみました。

本ブログでも自分用の ESLint 設定ファイル(GitHub)に本日から導入しています。