はてなブックマーク

OXCで正規表現パーサーを実装してるときに全部一通り読んでみて、みんな違ってみんな良いってなったので。 候補はこちらの3つ。 https://github.com/jviereck/regjsparser https://github.com/DmitrySoshnikov/regexp-tree https://github.com/eslint-community/regexpp かのAST Explorerでも、RegExp部門ではこの3つがリストにある。 AST explorer https://astexplorer.net/ 前提 ECMAScript本体だと、ESTreeというデファクトがあるけど、残念ながらRegExpにはない。 ESTreeでのRegExpの扱いはこんな感じで、ただの文字列でしかない。 interface RegExpLiteral <: Literal

Your shopping website is not an SPA. I repeat: your shopping website is not an SPA. Stop trying to sculpt David with a JS chainsaw and get yourself an HTML/CSS chisel. — Alex Russell (@slightlylate) 2021年8月10日 この主張、界隈（少なくとも自分の観測範囲）では割とよく見かけるし、なんか定期的に話題になるトピックなのかなーと。 まあ持論としてもコレには概ね同意しており、会社のスタンスとも相まって、常日頃からぼんやり考えてたりすることでもある。 で、そんな折にこのツイートを発見して、さらにそれに言及してる人々を見て、ふと自分でも現状を整理しておきたいなーという気持ちになったので筆を執った次第

何を今さらって感じではあるが、改めてそれを実感した出来事があったのでメモ。 メモリ制限 別の記事でも同じようなトピックに触れたばかりではあるけど。 https://developers.cloudflare.com/workers/platform/limits/#memory Cloudflare Workersのメモリ制限は、 Workerは、デプロイされた各CDNロケーションにおいて、1インスタンスのみ起動する その1インスタンスが、それぞれメモリ上限128MBの制限下に置かれる どこかのリクエストでメモリ上限を超えると、後続でエラーになるリクエストが出てくる Worker exceeded memory limit.エラーで503ステータスが返る その1インスタンスは、生存している限り、グローバル変数を使ってリクエスト間データ共有もできる 予告なくインスタンスは消滅する可能性がある

まとめたいなと思ったが、それは叶わぬ夢なのかもしれない・・・。 JSDoc.app Use JSDoc: Index https://jsdoc.app/#block-tags JSDocの本家（のはず）で、用途は主にドキュメント作成。 以下がその一覧で、AtoZ（エイリアスは別）順。 まずはブロックタグといわれるよく見るもの。 @abstract @virtual @access <package|private|protected|public> @alias <aliasNamepath> @async @augments <namepath> @extends <namepath> @author <name> [<emailAddress>] @borrows <that namepath> as <this namepath> @class [<type> <name>] @c

Linter | The JavaScript Oxidation Compiler https://oxc-project.github.io/docs/guide/usage/linter.html コントリビュートした記念としても、記録を残しておこうかと。 Oxcとoxlint oxc-project/oxc: ⚓ A collection of JavaScript tools written in Rust. https://github.com/oxc-project/oxc Oxcって名前は、Rustで書かれたJS向けツールセット群の総称みたいなもの。 Linter Parser Resolver Formatter Transformer Minifier etc… みたく手広くカバーしてて、eslintの置き換え（完全互換ではないが50x-100x速い）を目指してるのが、

久しぶりに、いわゆるポエムを。 新規・運用ヘルプを問わず、受託や副業でよくフロントエンドをやってるWeb屋の見解、そして手札のお悩み。 この先、また技術選定する際なんかにも参考になるかと思ったので。 React 「いまフロントエンドやるなら最初に覚えるべき！」は、もう過去の話かなーと個人的には思ってる。 Reactは`UI = fn(state)`なのが良い！とか言われるけど、あなたが必要としてるのは`UI = Component(props)`かもよって。 一昔前までは、たしかにあらゆる面で頭一つ抜けてる印象はあったけど、今はそうでもないか、その差はだいぶ埋まってきてると思ってる。（もちろん先行者利益みたいなところで、エコシステムはまだまだ優位な差があるかもしれんけど、それもあまり実感できたことはないし、いまからはじめる人はそんなんで困らんやろうし） 原初の時代からReactな案件をそれ

出オチですが、Cloudflare D1には、いわゆるSQLのトランザクションは実装されてない。 つまり、D1に対して発行されたSQL文の中に、BEGIN TRANSACTIONとか書いてあると、D1_ERROR: not authorizedとかいうエラーになる。 https://github.com/cloudflare/workerd/blob/e78561270004797ff008f17790dae7cfe4a39629/src/workerd/api/sql-test.js#L251 （もっとわかりやすいエラーメッセージにしてほしい） 代わりにbatch() D1 client API · Cloudflare D1 docs https://developers.cloudflare.com/d1/platform/client-api/#batch-statements 絶

昔々あるところに、既存のWeb APIの実装がありました。 それなりに実装を進めた後に、天の声が言いました。「OpenAPIのドキュメントを公開したい」と。 さて、あなたならどうする？っていうニッチな問いに対する一つの答えとして。 ルーターごと乗り換える？ たとえば今回でいうと、元のAPIはCloudflare Workersにデプロイされてた。 ので、たとえばhonoとかitty-routerとか、OpenAPIのドキュメント生成ができるエコシステムが整ってるルーターに乗り換えてしまうという手がある。 https://github.com/honojs/middleware/tree/main/packages/zod-openapi hono好きなあなたに https://github.com/cloudflare/itty-router-openapi/ itty-router好きな

ということをやりたくて、こうやったらできたという覚書。 やりたいこと こういうモノレポ構成とする。 - package.json - package-lock.json - packages - shared - app1 - app2 で、app1にあるコードベースを@myapp/app1とした場合、@myapp/sharedに置いたTSファイルを、そのままモジュールとして利用したいとする。 import { foo } from "@myapp/shared"; import { bar } from "@myapp/shared/bar"; // This is @myapp/app1 or @myapp/app2 code @myapp/app1と@myapp/app2は、それぞれ独自のコードベースになってて、それぞれtscではなくviteやesbuildなどのバンドラーを使う前提