S3、というより S3 API は、AWS というよりオブジェクトストレージ界の標準になりつつあります。S3 互換を謳うオブジェクトストレージはそれこそ毎月一個増えてるんじゃないでしょうか。 複数の CDN 構成をとるとき、クラウドごとのSDK のコードを書くのではなく、一つの実装(自分の場合 node の @aws-sdk/client-s3)で、全部のバケット処理を統一できないか考えて実験してみました。 APIごとに有効な機能、無効な機能で細かい差がありますが、この記事ではそこまで踏み込みません。 記事中の <key> や <secret> は自分で取得してください。 AWS S3 まずは普通に AWS に繋ぐコードです。 accessKeyId や secrentAccessKey の取得方法は省略します。 import { ListObjectsV2Command, S3Clien
node の S3Client から S3, GCS, R2 を操作するまだ検証足りないけど、マジで想像通りのブツなら魂震えるかもしれん...。 Announcing D1: our first SQL database Cloudflare D1 = Edge SQLite Cloudflare D1 は Cloudflare Worker で、つまり CDN Network 上で sqlite が動きます。これだけなら普通の sqlite ホスティングなんですが、もちろん Cloudflare が出すからにはそれだけではなく、CDN Edge 上に Read Replica がバラ撒かれた sqlite になります。ヤバくないですか? 僕はヤバいと思いました。 このヤバさを知るために、Cloudflare が開発した基盤についていくつか抑えておく必要があります。 Durable Objects は CDN 上の Actor モデルを構築できます。この Acto
Cloudflare D1 がヤバいフロントエンド開発はフロントエンドで完結すべき過激派としてのGWの活動で、ブラウザでローカルファイルを読み書きするターミナルのプロトを作ってみました。 ローカルファイルをマウントして操作してる風景です。 ソースコード mizchi/web-shell 仕組み FileSystemAccess API を使って、FS API を実装 xterm.js 上で FS を叩く Unix 風のコマンドをいくつか実装 monaco-editor で、open <file> した内容を渡して、Cmd-S で保存した内容をFSに書き込む 最初に開いてるのは navigator.storage.getDirectory() の一時的なストレージで、これはブラウザの機嫌次第で揮発します(仕様にそう書いてある)。ローカルファイルを操作するのに mount を使うのがメインの用途です。 FileSystemAcc
ブラウザからローカルファイルを操作するターミナルを作ったJS で wasm のダウンロードや TypedArry を通じた操作をやってると、コード内や localStorage にバイナリを埋め込みたいときがあります。 考え方 JS の内部エンコーディングは UTF16 と決められているので、UTF16で表現可能な範囲を1文字として、バイナリをインライン化すればサイズが小さくて済むはず Chrome は CompressionStearm でブラウザ内で deflate できるので、あれば圧縮する https://chromestatus.com/feature/5855937971617792 Chrome ではない場合、deflate 処理は飛ばしてそのまま。localStorage の読み書きなら途中でブラウザ自体のサポート増える/消えるなどしない限り一貫性は取れる 今回はやってないが、インラインJSに埋め込む場合、50kb を超えたあた
ブラウザ内でバイナリを圧縮してコードやlocalStorageに埋め込むこの本は、ブルーベリー本の 8 章からインスパイアされて、 TS の型が示す情報から Promise というものを理解してみる、というアプローチで書いたJSの非同期処理の解説です。 これらの資料と合わせて読むことを推奨します。 JSのイベントループのイメージを掴む JSでは中々意識することが少ないですが、正しく理解するには OS レベルのスレッドの視点で考え始める必要があります。 ブラウザや Node.js では一つのスクリプト実行単位を1つのスレッドに割り当てます。それをメインスレッドと呼んだり、ブラウザだったら UI スレッドと呼んだりします。 例えばブラウザでは、これは秒間60回、つまり 16.6ms ごとにループを呼び出します。(node だったらこれがもっと短いです) 仮に setTimeout の実装がなかったとして、それ相当の擬似コードを書くのを試みます。 let handl
イベントループと TypeScript の型から理解する非同期処理2章はプログラミング初心者に式と文という概念を伝えるのによさそう。コンパイラの概念が透けてみえるようになる。 let を避けろというコラムわかる。 BigInt の解説するんだ。 全体的にJSの言語仕様をTSという側面から解釈しつつ学ぶ、という構成になってる。この構成が初学者に伝わるかというと、完全なJS初学者には無理で他のプログラミング言語の経験は多少要求される。 3章 object への型注釈の文法解説が結構しんどく感じた。文法的に似てるがそれ故に混乱する。そういえば自分も複雑なインラインの型書いてると、今型なのかインスタンスなのか、結構間違ってる気がするので、言語自体が抱える特徴かもしれない。 type と interface の使い分け、今となっては何が何だかわからない気がした。type がない時代があってそれ以降は〜と書いてあるけど、昔の type はジェネリクスとれなくて、途中
プロを目指す人のためのTypeScript 本の感想 #ブルーベリー本Re: 僕らを縛る Node.js という呪いについて - あるいはなぜ TypeScript 以外が真っ当な選択肢にならなかったか https://d.potato4d.me/entry/20220405-nodejs/ へのアンサーソング。 プログラミング言語としての JavaScript の話をする。 2010年頃、Python 2 でプログラミングを学習した自分にとっては Node.js + CoffeeScript が Better Python だった。 CoffeeScript は当時の JS(ES3~5) に足りない機能を補ってくれて、Python と同じく空白制御のオフサイドルールなのが気に入った。見た目が少しだけ Ruby っぽいので当時全盛だった Rails の人間に訴求するにも有利だった。 Node.js のモジュールシステムである Commonjs は Pytho
Re: 僕らを縛る Node.js という呪いについて - あるいはなぜ TypeScript 以外が真っ当な選択肢にならなかったかbundlephobia.com というサイトがあります。これは npm のモジュールを参照した際のバンドルサイズを算出してくれるサービスです。 便利なんですが、基本的に dist/.. 等の package.json の main で配られるものだけをターゲットにしているので、 ESM Treeshake で一部のモジュールだけ import {} from ... した際のバンドルサイズがわからない、という問題がありました。 なので、それに対応したものを自分で作りました。netlify にデプロイしてあります。 こんな感じです。 使い方 https://shakerphobia.netlify.app/?pkg=<>&imports=<a,b,c> どうやって動いてるか URL を踏むと、 cdn.skypack.dev (その実体は npm) からソースコードを落としてきて、 Web
ESM treeshake に対応したバンドルサイズを計算してくれる Shakerphobia を作った(社内用ドキュメントの公開版) テストのポリシー 前提として、ユニットテストを導入するコストを、限界まで低くすることを目指す。テストが根付いていない言語環境や文化では、放っておくとテストが書かれないまま実装が進行し、結果としてテスト不可能な巨大な雪だるまが完成する。こうなるとメンテコストが高いE2Eを大量に書かないといけなくなり、テストの実行時間が膨れ上がっていく。 そうなる前に、ユニットテストを書きやすい環境を維持し、ユニットテストとして問題を切り分けられるような環境を維持する。とにかく書きやすさを重視し、一つのユニットテストを書くオーバーヘッドを限界まで下げる。 最初の一つを早い段階で書く 自分の経験的には、ユニットとテストの最初の一つを書いたらあとは自然とその周辺で増えていく。サンプルがあったら人はコピペする。逆にいうと最初の一つを書かない限り一切書かれない。まず一つ用意するのが大事
(自分の) JavaScript のユニットテストの書き方社内用の啓発記事ですが、閉じる理由がないのでここに投げます。 ブラウザにべったりなコードを書いてると、ブラウザや node.js 固有の環境をインラインで記述してしまうことが多々あると思います。 あえてダメダメなブラウザ向けのエントリポイントの例を書きます。 // main.ts let id = localStorage.get('id'); if (!id) { id = `${navigator.userAgent}-${Math.random()}`; localStorage.set('id', id); fetch('/auth', { method: 'POST', credentials: 'include', body: JSON.stringify({ id, at: Date.now(), }), headers: {'Content-Type': 'applicat
実行環境依存のコードに対してテストを書く考え方tl;dr node 14.19.0 で npm のバージョンを明示的に切り替える corepack が入った package.json の packageManager フィールドで npm 自体のバージョンや yarn の使用するバージョンを指定できる 詳しくは https://zenn.dev/teppeis/articles/2021-05-corepack 現状の npm-cli 自体が corepack に対応してないので、有効にしたければ npm コマンド自体を corepack に移す必要がある 現時点で packageManager を指定するだけだとまだ他の環境で有効にならないが、将来的に npm と node の corepack 対応が行き渡った時点で段階的に有効になる。 もっと詳しく # 手元の node を v14.19.0 以上に更新する # 自分は nvm
corepack でモジュールごとに npm クライアントを指定するビルドサイズ限界まで絞りたい人向け。 あらゆる環境で実践するものではないが、知ってたら簡単に避けることができるのもあるので知っておくと便利なTIPS書いていく。 基本ポリシー 未使用コードはビルド時に全部落とす。 何が未使用コードで、何が定数かわかるようなインターフェースを人間が心がける。 用語 Dead Code Ellimination(DCE) Rollup や Terser で、未使用コードを削除すること
JS のビルドサイズを極限まで絞るための TIPS 集Turborepo vercel が開発した monorepo 環境のためのビルドツールです。vercel ですが next 非依存です。 turborepo が何を解決するか node.js に限らず monorepo 環境下では、それぞれの内部モジュールのビルドは個別に行われることが多いです。ここでいう内部モジュールは、 package.json を持つディレクトリ単位、と捉えてもらって結構です。 apps/ web/ package.json # => foo, bar を参照 packages/ foo/ package.json dist/ index.js bar/ package.json # => foo を参照 dist/ index.js package.json このビルドが、(ビルドしない素の js と比べて)面倒な問題を引き起こします。 更新時にビルドを忘れて古い
turborepo で monorepo の差分ビルド自分が欲しかったから作ったシリーズ 説明しづらいので下記の動画を見たほうが速いです。 Shift を押している間だけオーバレイが有効になり、要素名をクリックすると vscode の該当行に飛びます。 今のところ vite + react のみの対応ですが、仕組み上、あらゆる UI フレームワークに適応可能です。 何が起きているか TypeScript transf ormer の仕組みで *.tsx の jsx 要素に data-sj-path="vscode://file/..." を付与する TypeScript AST は sourcemap 用の情報を持っている Node の parent を探索し、直近の関数コンポーネント名を探す Shift を押している間、 マウスでホバーされた要素が data-sj-path を持っているならオーバレイを表示 オーバレイ中の要素名をクリックした
React で展開された HTML 要素から vscode の生成元コードに飛ぶ 方法実際、コード量に比例して遅くなります。 これは tokenize のステップがなく、すべての構文ルールが正規表現を個別に実行するのが遅い理由でした。またそのせいで空白制御のために構文定義が冗長になっていました。 そのため、事前に tokenize ステップを用意し、pargen を事前に分割された token 列を受け取るパーサコンビネータとして再実装しました。(元の pargen はあれはあれで使いやすいので別実装になってます) mints v0.1 の ベンチマーク 試した環境は MacBookPro M1 Max 64GB です。 --------- 2416chars [tsc] 58ms [esbuild] 14ms [mints] 6ms [mints_para] 12ms --------- e2981chars [tsc] 14ms [esbuild] 1ms [mints
自作軽量 TS コンパイラが tsc より高速になった / mints v0.1世の中の TypeScript コンパイラが大きすぎるので作りました。 ここで試せます。 jsx と jsx pragma のサポートもしたので、 preact も動いています。 実装方針 ビルドサイズ第一 とにかく軽量に mints自体が他のコードをビルドするときの速度ではない点に注意 現状、まともなエラーレポートが出ない。エラーメッセージをインライン化するとビルドサイズが増えるため。 空白行と型情報を落とすだけ ES5 への変換や commonjs への変換は実装しない enum と constructor と jsx のみ transf orm する特殊対応をしている 真面目な構文解析をしてない 例えば 1+1*2 のような binary expression は結合順を解析してない。型を落とすだけなら不要 prettier でフォーマットされたコードはコンパイルできるのが目標(空白行
mints: 5.7kb の TypeScript コンパイラを作ったロマン構成が動いたので紹介します。 コード: https://github.com/mizchi/absurd-sql-example-with-typeorm デモ: https://heuristic-perlman-94f8f4.netlify.app tldr Steam の某クリッカーゲームをやってたら放置ゲーでも作りたい気分になってきた。 複雑なデータを管理するならブラウザ内に本物の sqlite を持ってきたい sqlite は持ってこれたけど TS の中で 生 SQL 書くのがだるかった(補完支援がない)ので ORM でラップしたい Typeorm + absurd-sql の構成を試したら色々大変だったけど動いた つまりブラウザでこのコードが動く。 // ... @Entity() class User { @PrimaryGeneratedColumn() id: nu
typeorm + absurd-sql on Browser のロマン構成yarn v3 が出ました。詳しい解説は譲るとして、esbuild integration や パフォーマンス向上が目玉です。 Yarn 3.0 🚀🤖 Performances, ESBuild, Better Patches, ... - DEV Community 流石に v1 はもう古いが、 v2 からの独自路線は受け付けがたい...という立場なのですが(yarn オリジナル作者の sebmck も難色を示しています)、今回は yarn 特有の機能をできるだけ避けて、できるだけ npm や pnpm 等と互換な部分だけで yarn v3 を使います。なので pnp も使いません。eslint や vscode の typescript 等でハマりどころが多すぎます。 ゼロインストールも否定派です。git blob objects のサイズが爆発して仕事にならなくなったことがあります。
yarn v3 の独自機能を避けつつ yarn v1 から v3 へのアップグレードをする※(注記)ただし IE は除く 問題 今までのフロントエンドの悩みの一つに、 publicPath の設定がありました。これはchunkを含むビルドした際に、chunk を解決するホストを明示的に指定する必要がある、というものです。 例えば、 https://cdn.example.test/assets/module.js に静的ファイルを配置する際、 publicPath として https://cdn.example.test/assets/ を指定する、という必要がありました。これはレガシーブラウザ環境だと module.js が自分自身がどのようなパスとして実行されているからわからず、相対パスのファイルのパスを知る方法がなかったのでビルド時に指定する必要があったわけです。 解決方法 現在、ESM なら import.meta.url、 <script src="..."></script
webpack / vite で public path の設定はもういらなくなっていた主張 現代では、 npm に publish するものを除けば TypeScript をコンパイルして配布する必要はほぼないと考えています。 TypeScript のコンパイルをしない環境、例えば deno や rome を使うと、コンパイルをするというステップが省くことで開発体験が大きく向上する、という肌感があり、ローカル環境ならこのメリットを優先するべきと考えています。 基本的に、ビルドはフロントエンド/サーバーともに配布前の最後の一回だけでいいはず、というのが自分の主張です。 Rome Toolchain Deno - A secure runtime for JavaScript and TypeScript 理由 現代の npm のお作法に従うと TypeScript に依存したものを npm の registry に置くことは、あまりよくないこととされていますが、モノレポ内や特
内部モジュールでは TypeScript をコンパイルせずに配るリリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く