JSで書かれたECMAScript RegExpパーサーの比較 | Memory ice cubes
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
TypeScript 5.5 で追加された正規表現構文チェックを理解する
TypeScript 5.5で、@graphemeclusterさんによって正規表現リテラルの構文チェックが導入されました🎉 この構文チェックによって、正規表現に間違いがあった場合、事前にTypeScriptがエラーを出力してくれます。 この機能について、次のことが気になったので調べてみました。 どんな構文がエラーになるか なぜ導入されたか どうやってチェックしているか JavaScriptで実行できるがTypeScriptでエラーになる構文はあるか ESLintとのカバー範囲の違い 本記事に関して、誤り等があれば指摘いただけると嬉しいです。 どんな構文がエラーになるか TypeScript 5.5では、正規表現に関するエラーメッセージが40個程度追加されています。 例えば、下記のような構文は、5.5でエラーになります。 // 存在しないフラグ var re = /a/b; // エラー
Maintainer Month: なぜtextlintを作ったか
今では200以上のルールがある自然言語のLintツールであるtextlintがどのように作られたかを振り返る記事です。 6月はMaintainer MonthというイベントをGitHubが主催しています。 Maintainer Month is a reminder for the ecosystem to support, celebrate, and compensate open source maintainers. – Maintainer Month Maintainer Monthは、オープンソースのメンテナーが集まって情報共有したり、メンテナーを祝ったり、支援したりするイベントです。 メンテナーがどういうサポートを求めているかを知る、負荷が特定の箇所に集中するエコシステムはバランスが悪いのでそれを支援する方法を知るといったことを思い出すのがMaintainer Monthの
全ての道はRomeへ続くのか - これからのJavascript開発を考える
Romeとは 現代のJavascript開発には多くのツールチェーンが必要とされます。Babel,webpack,Jest,ESLint,Prettier,Typescriptなどを組み合わせて開発することが多く、さらにこれらの一部代替選としてesbuild,SWC,Viteなどのツールチェーンの選択肢が存在し、選択肢の多さやその組み合わせの複雑さに苦い思いをしたことがある方も少なくないのではないと思います。 こうした中で、新たに開発が進められているツールチェーン、Romeをご存知でしょうか？ Romeは先に挙げたように複数のツールチェーンを役割ごとに組み合わせて使うのではなく、1つのツールチェーンでこれら全ての役割を担ってしまおうという壮大な計画を持つツールチェーンです。 Romeは2020/03にFacebookより発表されました。現在は法人化され、yarnやBabelの生みの親である
JavaScriptのリファクタリングツール「jscodeshift」の使い方 - Qiita
はじめに JavaScriptのコードを一括で変換したり修正したい場合、正規表現などを使い置換しますか？ シンプルなケースであればそれでも問題ないですが、複雑な変換であればASTベースでコードを自在に変換できる「jscodeshift」が便利です。 jscodeshiftを利用すると、以下のようなことができます。 例) functionで書かれた関数をアロー関数に一括で変換 target/arrow-function/index.js const fn = function() { console.log("foo"); }.bind(this); [1, 2, 3].map(function(v) { return v * v; }); Promise.resolve() .then(function() { console.log("foo"); }) .then(function()
JavascriptのObjectリテラルとJSON.parseについて - abcdefGets
V8のJSON.parseについて 最近(ちょっと前か)話題のオブジェクトリテラルよりもJSON.parseのほうが早い件について。 その理由を内部実装の観点から書く。 また注意点を最後に書いた。 話題のブログは以下から https://v8.dev/blog/cost-of-javascript-2019 パースについて V8はjavascriptコードをパースするにあたって、Lazy Parseを行っている。 Lazy Parse javascriptはブラウザという特殊な環境で実行される言語であるため、パースにも少々工夫が必要になる。 基本的にV8はすべてのソースコードをパースしない。 一旦グローバルスコープにあるものだけをちゃんとパースして、それ以外はPreParserというパーサで関数だけをかき集める。 function foo() { } function bar() { fu
TypeScriptの型情報を利用したCustom Transformerの現状確認 - Islands in the byte stream
TypeScriptのコンパイラ・プラグインとして振る舞いASTの操作を行えるcustom transformer (AST preprocessor) が実装されたのは TypeScript 2.4 (2017年) でした。 そのときの様子は次のエントリに非常によくまとまっています。 [TypeScript 2.4] custom transformer を利用して実行時に型情報を参照可能にする - Qiita さて、現在のTypeScript v3.3 でのTransformer APIの状況はというと、TypeScript compiler本体としては依然としてドキュメントに乗ってない水準の扱いです。特に、コンパイラAPI そのままではtransformerは型情報を利用できません。ts.TransformerFactory に渡される ts.TransformationContex
社内勉強会 TechLunch で"JavaScript AST ことはじめ"という発表をしました | MEDLEY Developer Portal
2018-06-22社内勉強会 TechLunch で"JavaScript AST ことはじめ"という発表をしましたみなさん、こんにちは。開発本部エンジニアの平木です。こちらのブログの投稿自体はほぼ 1 年ぶりになりそうな勢いですが、みなさまお元気でしょうか? 弊社で定期的に開催してる社内勉強会 TechLunch で自分の順番が回ってきたため、どうしようか迷った末にJavaScript AST ことはじめという発表をしたので、そのことについて書いていきます。 なぜ JavaScript AST について話そうと思ったのか現在、弊社のエンジニアメンバーのバックグラウンドで一番多数派なのは「元サーバサイドエンジニア」です。もちろん、業務ではサーバサイド・フロントエンド・ネイティブアプリとバックグラウンドに関わらず、必要に応じて分け隔てなく開発しています。 とはいえ、ちゃんとサービス開発自体
Node.jsでつくるNode.js - もくじ - Qiita
はじめに 「RubyでつくるRuby ゼロから学びなおすプログラミング言語入門」(ラムダノート, Amazon) という本を手を動かしながら読んで、非常に感銘を受けました。そんなおりに PythonでつくるPythonという記事を読み、自分でもNode.jsでミニNode.js作りにチャンレンジすることにしました。 予想以上に手間取り端折った部分もありますが、なんとか最後はブートストラップまで行くことができました。 目次 ミニインタープリター編 Step1：ソースのパース ... 初めての esprima Step2：単純化 ... 抽象構文木(AST)を単純化 Step 3: +演算子を評価する ... 足し算を実行 Step 4: 四則演算で電卓を作る ... 電卓を作るところまでと、比較演算子の実装 Step 5: 変数を使う ... 変数の宣言、代入、参照 Step 6: 条件分岐
Source to Binary - journey of V8 javascript engine
V8 javascript engineについて パーサー、AST、Ignition/TurboFan、最適化周り等
さよならボイラープレート。s2sによる高速reduxアプリケーション構築 - Qiita
まだアクションクリエイターを自分で書いているの？ reduxとflowtypeを使ってフロントエンドアプリケーションを構築していると、ボイラープレートが多く、面倒だと感じることがありませんか？ しかし、もはや、このAST時代の前には過去の悩みでしかありません。 型を書く。それが全てです。 型を書いて、定数を書いて、アクションクリエイターを書いて、一つ変更したら全て変更して、もしくはなんらかのハックを行って型付けして、なんてものは過去のことです。 これからは、アクションクリエイターの作成に5秒以上時間をかけたら怠惰でありましょう。そして、これはs2sの1プラグインでしかありません。 プラグインを組み合わせると以下のようなこともできます。 s2s (Source to Source) これを実現している仕組みをSource to Source(s2s)といいます。 ソースコードからソースコード
V8 javascript engine for フロントエンドデベロッパー
V8 is Google's open source JavaScript engine that is used in Chrome and Node.js. It uses several optimization techniques like hidden classes, inline caching, and TurboFan to improve JavaScript performance. V8 first parses JavaScript into an AST, then compiles it into bytecode which is executed by the Ignition bytecode interpreter or optimized by TurboFan into machine code using techniques like hid
Releasing Prettier 1.0
This post was written by vjeux and edited by jlongster. We officially announced prettier over two months ago as a way to solve the problem of wasting time formatting your code. It started as an experiment but it clearly resonated with a lot of people, amassing ~7000 GitHub stars and over 100,000 monthly npm downloads in just two months. In case you don't know, prettier is a JavaScript formatter th
A Prettier JavaScript Formatter
Today I am announcing prettier, a JavaScript formatter inspired by refmt with advanced support for language features from ES2017, JSX, and Flow. Prettier gets rid of all original styling and guarantees consistency by parsing JavaScript into an AST and pretty-printing the AST. Unlike eslint, there aren't a million configuration options and rules. But more importantly: everything is fixable. I'm exc
Node学園 20時限目 アウトラインメモ
Node学園 20時限目に参加したきたのメモ。 「eslintの話」 by @mysticatea スライド: ESLint Past and Future - Google スライド ESLint 12-3% ぐらいのルールを書いた JSHintにプラグイン機能が追加するという話はあったけどならなかった ESLintの特徴 ASTベースでプラグインという特性 (以前書いたプラグインの仕組み: ESLint | JavaScript Plugin Architecture) 開発者が貢献するのが簡単 コントリビューションガイド 開発体制 機能に関しては Reviewer以上 バグに関しては Committer 以上が確認してマージ 隔週の金曜日にリリース ESLint 3.0.0 Stage 4に到達した構文 Auto FixはIDEと連携して選択式の適応へ アグレッシブなFixは同時に適
JavaScriptのコードを分解してよく使われてる機能を分析する
今年のOSS活動振り返り @ 2015 | Web Scratchで JavaScript/ECMAScriptを改めてどう学べばいいのか考える azu/how-to-learn-es6とか#thinking_in_es6で考えてるやつ というのを今年考える事としてあげていました。 それを考えるために、既存のコードがどうなってるかを見てみるという話です。 具体的には既存のコードを見て、そこでどういう機能/構文が多く使われているのかが分かれば、どこを中心的に学ぶと結果が出やすくなるのではという感じです。 それを分析するためにazu/es-usage-rateというツールを書いた。 Installation 使い方 例えば、es-usage-rate自体がどういう構文を使って書かれてるかを見てみてます。 es-usage-rateは他のCLIと組み合わせて使う事を前提としてるので、 デフォルト
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
外部ライブラリもインストール・型解釈できるTypeScript playgroundを作った
GitHub - vtrushin/json-to-ast: JSON AST parser
Change your source with AST
GitHub - prettier/prettier: Prettier is an opinionated code formatter.
