コードフォーマッターはコードを削除することもある | Memory ice cubes
いやそれはバグでは？って思うかもしれないが、実はそうとも言い切れない・・・というか、PrettierもBiomeももちろんOxfmtも、既に同じようにそう動いてるし。 つまりは、特定の条件が揃った時には、コードの一部を削除しても問題ない、ということになってるってこと。少なくとも、コードの挙動には影響を与えないなら。 あらすじ そもそもコードフォーマッターは、コードの挙動を変えることはない、と思うのがまあ一般的な理解かと。 つまりは、改行を足したり消したり、スペースを空けたり詰めたりはしても、ASTに現れるような具体的なコード片にはノータッチなんでは？という認識だった。 つまり、 コードをASTにする ここでいったんスナップショット(BF)を保存 ASTをフォーマッターに渡してフォーマット そのコードを再びASTにする ここでまたスナップショット(AF)を保存 そして、BFとAFでスナップシ
`@typescript-eslint/parser`と`@typescript-eslint/typescript-estree`の関係 | Memory ice cubes
ちゃんと区別できてなくて、地味に誤解してたことに気付いたのでメモしておく。 それぞれの役割 @typescript-eslint/parser https://typescript-eslint.io/packages/parser @typescript-eslint/typescript-estree https://typescript-eslint.io/packages/typescript-estree 最初はestreeのほうが表向きのパッケージで、内部的にparserを使ってるのかと思ってたけど、まったくの逆だった。 parserこそがESLintのための表向きのパッケージで、純粋にASTだけ取り出したい場合は、typescript-estreeのほうをそのまま使えばよさそう。 parser側のコード 2つの関数がexportされてる。 parseForESLint() h
入門Cloudflare Workers
はじめに この記事はCloudflare Workersの入門記事です。 名前は聞いたことがあるけれどCloudflare Workersが何者か知らない方 「Cloudflare Workersはサーバーレス・エッジコンピューティングサービスだよ」と説明されて日本語でOKと感じた方 AWSのLambdaやGCPのCloud Runと似たコンセプトのサービスだろうと認識されている方 上記に当てはまる方のお役に立てるはずです。 開発環境の構築 まずは開発環境を構築しましょう。といっても、最新のnode.jsをインストールするだけです。 インストールできたらバージョンを確認しておきましょう。 補足 v16.13.0より新しいバージョンのnodeが必要になります。記事を読み進めて不具合が発生した場合はnodeのバージョンを確認してください。 Windowsの動作検証はしていません。ここから先の手
TypeScriptのASTにおける`JSDocXxxType`というノード | Memory ice cubes
たとえば、JSDocUnknownTypeとか。 TSなのにJSDoc？どういうことやねん！ってなった我々（自分だけ）は、調査のためにアマゾンの奥地へと向かった・・・。 OXCでの出会い まず最初にこれを見たのは、OXCのTS ASTを眺めていた時。 https://github.com/oxc-project/oxc/blob/d48e8864d32a42664d2aa96bbdcf287828a5904d/crates/oxc_ast/src/ast/ts.rs#L1626-L1654 この3つが定義されてる。 JSDocNullableType JSDocNonNullableType JSDocUnknownType JSDoc接頭辞はついてるけど、いわゆるJSDocコメント内の話ではない。 だってコメントの中身の型情報まではパースしないから。 どうやったらASTとしてご対面できる
Jest再入門 - カスタムマッチャー作成編 | 豆蔵デベロッパーサイト
最初は、シンプルなケースでカスタムマッチャーを作成します。 ここではUUIDのフォーマットが正しいことを検証するマッチャーを作成してみましょう。 まずは、Jestのカスタムマッチャーです。この場合は以下のようなマッチャー実装になります。 expect.extend({ toBeUUID(received: unknown): jest.CustomMatcherResult { if (typeof received !== "string") throw new Error("actual value must be a string"); const pass = /^[\da-f]{8}-[\da-f]{4}-[\da-f]{4}-[\da-f]{4}-[\da-f]{12}$/.test(received); const message = () => { return pass
UnJS にどんなツールがあるのか、上位30件すべて紹介してみた（前編）
タイトル通り、JavaScriptツール群「UnJS」にどんなライブラリが存在するのかをひたすら見てみよう！ という記事です。 本当は全て紹介しようと思ったのですが、全75個あり、1つの記事に入れるとあまりにも多すぎるので、この記事では2023年11月4日時点のStar数の順に沿って上位30個を紹介していきます。それ以降のリポジトリは別の記事で紹介していますので、気になった方はこの記事の後に読んでみてください。 UnJS とは UnJSは、Nuxt 開発チームが中心となって開発・メンテナンスされている、あらゆるJavaScriptフレームワーク上で統一的に動作するユーティリティーツール・ライブラリ群です。 UnJSというプロジェクトが何であるかについては、2022年11月に公開された講演映像「UnJS: Nuxt 3 behind the scenes by Pooya Parsa」を観て
なぜ不変なオブジェクトを useEffect, useCallback, useMemo の依存配列に含めるのか: react-hooks/exhaustive-deps のフェイルセーフ
なぜ不変なオブジェクトを useEffect, useCallback, useMemo の依存配列に含めるのか: react-hooks/exhaustive-deps のフェイルセーフ ESLint の react-hooks/exhaustive-deps ルールを使っているときにフェイルセーフの大切さを見出す場面があったので書き記しておきます。 不変のオブジェクトは依存配列に含める必要がない ESLint でreact-hooks/exhaustive-deps ルールを有効にすると、useEffect や useCallback 、useMemo といったフックの依存配列に漏れがある場合に検知してくれます。 ただし、これらのフックの依存先に不変のオブジェクトがあるとき、不変のオブジェクトを依存配列に含める必要はありません。 例えば、以下の useCallback では setCo
僕らを縛る Node.js という呪いについて
これ僕らの物語であり、僕と君の物語であるかもしれない。 数日前、友人が言った。「久しぶりに Rails を書いたけれど、Node.js の良さに敵わない」と。 その言葉に同意しながらも、他方で少し不思議に思う。 いつから僕らは Node.js しか使わなくなったのか。あれだけ話していた Rails などの多くの Web 技術にときめかなくなったのか。と。 もちろん、使えないというわけではない。寧ろ今現役で十分な活躍をしているフロントエンドの人間は、等しく皆「主役であるバックエンドのサブとして存在するフロントエンド」を経験してきている。 書こうと思えば書ける。だがその中で、敢えてフロントエンドとその技術を選んできた。 だけど今はどうだろう。フロントエンドエンジニアはもはや「JavaScript を扱うソフトウェアエンジニア」となり、一般的なバックエンドは勿論、Node.jsが一級市民として存
neverthrow の全機能リファレンス
JavaScript/TypeScript で try/catch を使わないエラーハンドリングに利用できるライブラリとしてはそこそこ有名だと思う neverthrow ですがあまり解説された記事が少なく、関数型と手続き型の書き方をいい感じにミックスできるいいライブラリで情報の少なさから選択されないのも勿体なく感じました。ちょうど GitHub のドキュメントを読みながら意訳してまとめた手元の技術メモがありますのでその一助になればと公開します。 neverthrow とは supermacro/neverthrow: Type-Safe Errors for JS & TypeScript プログラムのエラーハンドリングを try - catch ではなく関数型プログラミング由来の Result 型や Either 型と呼ばれる方法で実現する機能を提供するライブラリです。具体的には Res
若い世代が知らない2000年代のHTMLコーディングの地獄 - ICS MEDIA
ウェブの黎明期である2000年頃と比べてはるかにHTMLはコーディングしやすくなりました。10〜20年前のHTMLコーディングはどのようなものだったのでしょうか。 この記事では、NetscapeとIEのブラウザ戦争に決着がついた後の、IE6が全盛期となった2000年代のウェブサイト制作を振り返ります。懐かさに浸たり、現代のウェブの成り立ちに通じる温故知新な情報として参照ください。 テーブルレイアウト / spacer.gif XHTML・CSSが普及するまではテーブルレイアウトが一般的でした。テーブルレイアウトとはtableタグを使い、格子状にレイアウトしていく手法です。テーブルレイアウトは、デザインファイル（Image ReadyやFireworks）から画像を切り出す「スライス機能」と相性のいい方法でした。 <table border="0" cellspacing="0" cellp
機能が無いことに依存していた例 esbuild-register編
上の引用部分をよく読むと、Experimentalと書いてあるのが目につきます。通常、実験的な機能は安定しているとはみなされず、メジャーアップデートではなくても壊れうるものと考えられます。 実際、ここで使われているNode.jsの--loaderオプションも実験的機能です。そのため、マイナーアップデートで壊れたとしても取り立てて騒ぐことではないようにも思えます。 しかし、今回の壊れ方の中身まで見ると、実験的機能だから壊れたというより、機能追加によって壊れたと見なした方が適当に思えます。そこで、この記事では「機能が無いこと」に依存していた例として紹介します。 ちなみに、このESM向けフックの機能は、Node.js 20.6.0で「Release Candidate」という安定一歩手前の状態に昇格しました。 動かなくなったことはこちらのissueで報告されています。このissueでは、esbu
Re: 僕らを縛る Node.js という呪いについて - あるいはなぜ 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
バックエンドもフロントエンドもインフラも Terraform でつくってみた
この記事は terraform Advent Calendar 2024 の 9 日目の記事です。 Terraform だけでアプリケーションのバックエンド・フロントエンド・インフラをつくったので紹介します。 つくったもの 利用技術 バックエンド フロントエンド インフラ まとめ つくったもの 画像を表示するだけのサンプルアプリケーションです。 Gallery リポジトリはこちら。 使用言語 利用技術 バックエンド バックエンドの実装には次世代のモダン AltJS である JS.tf を使用しています。 JS.tf を使うと HCL で JavaScript プログラムを記述することができます。 data "js_function_call" "hello_world" { caller = "console" function = "log" args = ["hello world"]
UMD を出来るだけシンプルに説明してみる - 強まっていこう
何？ Node.js とブラウザの両方で強引にコードを読ませるための暴力的な書き方 実例 public/js/umd.js にモジュールが存在し、そこが Web でも公開されているとして呼び方は以下のようになる Node.js で呼ぶ場合 #!/usr/bin/env node const UMD = require('./public/js/umd') const umd = new UMD() umd.say() ブラウザで呼ぶ場合 script(src='/js/umd.js') script. const umd = new UMD() umd.say() こんな感じで Webpack とかしなくても普通に読めるようになる モジュールの書き方 ;(function (root, factory) { if (typeof define === 'function' && defin
JavaScript で Hello,world! に挑戦 (ただし記号だけを使って) - Atsumaru Engineer's Blog
どうも、趣味で JavaScript を書いている三井です。 先日、 JavaScript つまみ食い LT 会 というイベントを主催しまして。 そのメインの LT 会後の懇親会で「懇親会 LT」と銘打ったゆるゆる LT をやりました。 私も参加して「JavaScript で Hello,world! に挑戦」という話をしたんですが、その資料が Web に上がっていないので(というか資料無しで話したので)この場を借りて話した内容をまとめてみます。 何をやる？ ブラウザに Hello,world! を表示させる JavaScript プログラムを 記号だけ 使って書きます。 プログラムを学び始めた人がまず最初に取り組む課題が Hello,world! を表示するだけのプログラムを書くというもの。 いまいちど初心に立ち返って記号だけで Hello,world! を書けば、 JavaScript
安全な文字列であると型で検証する Trusted Types について | blog.jxck.io
Intro 脆弱性の原因となる DOM 操作の代表例として elem.innerHTML や location.href などが既に知られている。 こうした操作対象(sink) に対して、文字列ベースの代入処理を行う際に、一律して検証をかけることができれば、脆弱性の発見や防止に役立つだろう。 そこで処理前の文字列に対し、処理後の文字列を安全であるとして明示的に型付ける TrustedTypes という提案がされている。 まだ未解決の部分が多い提案だが、現時点での仕様と実装を元に、このアイデアについて解説する。 WICG/trusted-types Intent to Experiment: Trusted Types Sink XSS などの原因となる DOM 操作として、DOM に直接文字列を展開する処理がある。 element.innerHTML location.href scrip
YappoLogs: 2014年に向けた JSON API の実装の方向性と X-JSON-Status 改め X-API-Status header のご提案
2014年に向けた JSON API の実装の方向性と X-JSON-Status 改め X-API-Status header のご提案 追記 2014/11/20 14:00:00 わりと JSON やら XML やら各種フォーマットで API を運用している環境がある場合に JSON API の時だけ X-JSON-Status にすると XML とかの時と整合性取れないし、 X-XML-Status みたいのを量産するのは困る的なレビューを頂いたので X-JSON-Status をやめて X-API-Status にしました。 へたに JSON に限定するから REST とか JSON-RPC とかいわれるんや！ X-API-Status にしたら全部解決したし MessagePack な API でも使い回せるって songmu さん言ってた！ XML とかからどうやって引っこ抜
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
【JavaScript】オブジェクトをfreezeした後でもprivateプロパティを変更できるし生やすこともできる - Qiita
AVAでswc-nodeを使ってTypeScriptで書かれたテストを実行するための設定 - Qiita
スマートで便利な Polyfill 配信サービス Polyfill.io - 無駄と文化