Viteで古式ゆかしいasset環境を作る
実現したいことVite で古式ゆかしい asset 環境を作る。 Vite | Next Generation Frontend Tooling 前提古式ゆかしいとは以下の状態を指す。 JS としてのエントリポイントが複数あるasset manifest でコントロールしない（hash を付与しない）本来 Vite は Parcel Bundler 以降の時代の代物なので、HTML を食わせると元の HTML も含めて entry point から芋づるで関連ファイルを変換、圧縮などよしなにしてくれる。その際、処理後のファイル名に何らかの hash 値を付与してくれるので、特に難しいことを考えずとも CDN などでの強いキャッシュを実現でき、asset 転送の負荷が自動的に削減されるありがたい仕組みである。 しかし今回はこの挙動を変えて、上の状態を目指す。 Vite は基本的にはフロントエ
Stimulus、悪くない
Stimulus: A modest JavaScript framework for the HTML you already have. 2020年末にリリースされた Stimulus 2.0 を試して気づいたことをメモしておく。Stimulus は Rails で有名な Basecamp のメンバーによって開発された生 DOM をベースに、できるだけ template に JS を書かずに動的な DOM の生成、変更を実現するためのライブラリである。 昨今流行りの React, Vue, Angular などの VirtualDOM 系のツールとは根本的に考え方が異なり、今からこれを採用するのはやや申し訳ないというか、正直に言うとよいイメージはなかったし、例えばフロントエンドエンジニアとしてスキルアップしたいぜーという人には合わないと思うが、ただ、どうせサーバサイドの開発が必要で、分
2016年に設計なんてない、そこそこの量のJavaScriptのエラーを監視して対策し始めました雑感
公開されるどこにも記録を残していないような気がするが、2016年の初めからとある事情により JavaScript のエラーをサーバに送りつけて監視サービスに送りつけてエラーの発生を知り、修正する、ということを地味にくり返していた。 そこに至る顛末と今後の分析の予定のお話。 背景これまで扱ってきたものはそこまで JS ヘビーでないものが多く、また自分で書くものはできるだけユニットテストが動くように書いていた and そもそも監視サービスが入っていなかったので、エラーのログをサーバに送るとか監視するとか、そこまで手をかけていなかった。 しかし今回の案件は初期の設計では考えてもみなかった量のカウボーイスタイル JS がコミットされしまい、要するに非常にイキのいいフレッシュなレガシーコードがてんこ盛りで動いている状態になってしまった。 （あーはい、全部ぼくがコードレビューしてリジェクトすれば防げた
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
