はてなブックマーク

formatter: built-in sorting and aesthetically features · Issue #13610 · oxc-project/oxc https://github.com/oxc-project/oxc/issues/13610 これを検討するにあたり、まずは市場調査を・・・ということで。 どういう関心が世にあって、どういう先行実装があってどう違ってて・・・みたいなことをざっくり知りたかった。 (不備や有力情報があったらぜひ教えてください。) 最初におまけ: Stylisticなツール 最初に思い当たるのは、やはりeslint-stylisticかな? eslint-stylistic/eslint-stylistic: Monorepo for ESLint Stylistic plugins and configs https://github

知ってる人は知ってると思うけど、せっかくブログがあるんやし、記念に書いておこうと。 いままで 株式会社ピクセルグリッド / PixelGrid Inc. https://www.pxgrid.com/ "株式会社ピクセルグリッド"という会社で、主にフロントエンドのエンジニアをやってました。 そして実はこの会社を辞めるのは2回目。というのも、一度は辞めたけど、出戻りをしていて、そしてまた辞めるという。 そういう経緯なので、トータルの社歴という意味では、3 + 5 = 8年ほどということになり、もちろんキャリアの中で最長の会社だったりする。 投稿記事一覧からざっとまとめた後半戦としては、 相変わらずのReact SPA三昧からはじまり Next.jsを通って、Svelte(Kit)派に改宗し SolidやVueも副業でやったりしつつ Cloudflareでニッチな需要を満たしながら Remix

というのも、簡単には使えないから・・・。 SharedArrayBuffer SharedArrayBuffer - JavaScript | MDN https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/SharedArrayBuffer 某Spectreの絡みでセキュリティ要件が厳しくなって、現世では簡単に使えなくなった。 httpsであることはもちろん crossOriginIsolatedなドキュメントである これらの条件が満たされていないと、SharedArrayBufferを使うことはできない。というか、条件未達の場合SharedArrayBufferがそもそもグローバルに存在しない。 COI: Cross-origin isolated Window: crossOri

祝リリース記念。 Astro 5.0 | Astro https://astro.build/blog/astro-5/ というわけで、このブログもアップデートした。 正直マイグレーションガイドに従っただけではあるが、何をやったか簡単に書いておく。 Upgrade to Astro v5 | Docs https://docs.astro.build/en/guides/upgrade-to/v5/ ちなみに、このブログはただの静的サイトなので、目玉アップデートたちとはあんまり関係がない。 Legacy: v2.0 Content Collections API Content Collectionsといって、ローカルにおいてある.mdや.jsonを元に、ページ生成できる機能がありまして。 Content collections | Docs https://docs.astro.buil

昨日、年初からぼちぼちやってたOXCに関するOSS活動で、書き留めておきたいことが2つ起きた。 OSSで報酬をもらった OXCのコアメンバーになった たぶん単発だったらブログに書いてないけど、同時多発になんか新鮮な気持ちになったので。 OSSで報酬をもらった OXCに古くからあるIssueで、oxlintにeslint/no-invalid-regexpのルールを実装したいというものがあって、それに対してかかってた50ドルの懸賞金をもらった。 [50ドル Opire Bounty] feat(linter): eslint/no-invalid-regexp · Issue #611 · oxc-project/oxc https://github.com/oxc-project/oxc/issues/611 単純なルールでありつつも簡単に実装できるものではなく、実は「正規表現のパーサーそのも

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速い)を目指してるのが、

先日、ここ1年くらい?ずっと音沙汰がなかったSolidStartに動きがあり。 Release v0.4.0 - Beta 2 · solidjs/solid-start https://github.com/solidjs/solid-start/releases/tag/v0.4.0 何が変わったかなーって見てたら、ほぼ全部書き直して150ファイル10000行から32ファイル1400行になったと。 (もちろん外部ライブラリに逃しただけなので、総量はそんなに変わってないとは思うけど) 一番の変更点として、NitroとVinxiを採用したらしいので、そのあたりどう棲み分けしてるのかをまとめておこうかと。 Nitro unjs/nitro: Create, build and deploy universal web servers. The open engine powering Nux

久しぶりに、いわゆるポエムを。 新規・運用ヘルプを問わず、受託や副業でよくフロントエンドをやってる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などのバンドラーを使う前提