GraphQL 界の Babel こと Envelop を使ってスキーマの破壊的変更をごまかす
この記事は LayerX のエンジニアブログがたくさん出る #ベッテク月間 の8記事目になります。こちらのカレンダーに、これまでの記事と今後出る予定がまとまっています。 LayerX のバクラク事業部には GraphQL Gateway というバクラク全プロダクトから参照される GraphQL スキーマが存在します[1]。今回の記事は、その GraphQL Gateway のスキーマをより良い状態にしていくためにぶつかった課題を強引に突破したときの話です。 モチベーション GraphQL スキーマの破壊的変更によって GraphQL Document がスキーマに適合しなくなる場合、そのリクエストはエラーになります。例えば以下のようなケースが考えられます： 使わなくなったフィールドを削除したい 削除されたフィールド（存在しないフィールド）を含む Document を処理することはできない
🔮
🔮 自己紹介 Name : azu 🐦 Twitter : @azu_re 📝 Blog: Web scratch, JSer.info 📚 Book: JavaScript Primer 🏗️ Develop: textlint, secretlint, HonKit OrbStack OrbStack · Fast, light, simple Docker & Linux on macOS Drop in replace Docker for mac 早い、ファンを回さない、便利 GUIがまとも OrbStackの特徴 Portを開けなくてもContainerに直接アクセスできる Container側portをexposeしなくても、macOS側からアクセスできる node --inspectorのようなデバッガーを外から接続するのに便利 macOS側にOrbStackのC
TypeScript 5.2で予告されているusingをいじってみる
この記事でのusing宣言の動作はBabelのtransform及びes-shimsのpolyfill実装に依存しており、実際のV8エンジンやTypeScriptのトランスパイル出力の挙動とは異なる可能性があります。 以下の挙動がusing宣言に対応している処理系の実際の挙動と異なる場合はコメントをいただけると幸いです。 導入 先日、Twitterでこんなツイートが回ってきました。 TypeScript 5.2で新しい「using宣言」が追加されるというものです。 しかも、TypeScriptの独自構文かと思いきや、JavaScriptのStage 3のProposalをTypeScriptで先行実装するという通常のTypeScriptの実装プロセスに則ったものでした。 新しい変数宣言の追加はES 2015(ES6)の「let」「const」以来でなんと8年ぶりで、JavaScript/T
ECMAScript Decorators の変遷と最新仕様 - Qiita
はじめに 個人的に TC39 meeting をウォッチしてまとめている @petamoriken です。 ECMAScript の Decorators の提案は何度も改定しています。その割にあまり知れ渡っていません。この記事ではその変遷と最終的な Decorators の仕様について簡単にまとめようと思います。 この発表スライドを見ると流れがわかりやすいかもしれません。 最初の提案（2014年~2015年頃） 最初の提案はこのような形式をしていました。 class Person { @nonenumerable get kidCount() { return this.children.length; } } function nonenumerable(target, name, description) { descriptor.enumerable = false; return
実践 Node.js Native ESM — Wantedlyでのアプリケーション移行事例 | Wantedly Engineer Blog
Wantedlyではこのたび、フロントエンドアプリケーションのひとつをNative ESM化しました。本記事ではNative ESM化の必要性と、必要な作業について説明します。 この記事の概要Node.jsにはNative ESMというモードがある。Native ESMはまだ普及していないが、ライブラリ側の更新が進み、移行が必要になりつつある。Native ESMをめぐる状況は (この記事の長さからわかるように) 色々複雑で、概念をちゃんと説明するだけでも大変。Native ESMへの移行にあたってはさまざまな困難が待ち受けている。Native ESMとは歴史的経緯から、JavaScriptには複数のモジュールシステムがあります。そのうちNode.js周辺でよく使われるのはCommonJS ModulesとES Modulesです。 CommonJS Modules (CJS) は実質的に
Native ESM + TypeScript 拡張子問題: 歯にものが挟まったようなスッキリしない書き流し
Node.jsのNative ESM対応は夢の機能ですが、夢を詰め込みすぎたせいかCJSからの移行を難しくしているポイントが依然として存在します。そのひとつが拡張子問題で、Node.jsのNative ESMではモジュールの拡張子を明示しなければいけなくなりました。 (これはWebブラウザの挙動に近づけるための判断だと考えられます。) 特にTypeScriptと他のツール (JestやWebpack) と組み合わせて利用している状態でのNative ESM化は実質的に未解決の状態だと言えます。本稿ではこの現状についてできる範囲で状況説明を試みます。 Node.jsの拡張子の扱い Node.jsはCJSとESMの2つのモジュールフォーマットをサポートしていますが、これらは単にパーサーが異なるだけではなく、実質的には「2種類の異なるモジュールシステムがFFIで繋がっている」程度には隔たりがあり
Babel が Flow から TypeScript に移行した
先日 Babel のメンテナーとして知られる Nicolò Ribaudo 氏が次のツイートを投稿した。 We finally finished migrating the Babel monorepo from Flow to TypeScript! It has been a very long process started by @z_bodya, and after migrating package-by-package @JLHwung just opened this PR 😄 pic.twitter.com/WKXxV8x2MY — Nicolò Ribaudo 🏳️🌈 • 💙💛 (@NicoloRibaudo) July 23, 2022 そう、JavaScript のトランスコンパイラである Babel のソースコードが Flow から TypeScrip
ライブラリ作者におすすめしたいBabelの新機能 babel-plugin-polyfill-corejs3 | Wantedly Engineer Blog
Babelの新しいpolyfill用プラグインであるbabel-polyfillsが2022年4月に脱experimentalを果たしていました。そこで本稿では、Babelにおいてpolyfillがどのように扱われていたかを振り返りながら新しいpolyfill pluginを紹介します。 注意: Babel 7.4で非推奨化された@babel/polyfillとは別物です。 何が問題だったのか?babel-polyfillsのREADMEと元issueにも説明がありますが、本記事ではあらためて日本語で説明したいと思います。端的に言うと今までは以下の要件を両立できませんでした。 ソースコード中で使われている機能のpolyfillだけを注入する。ターゲットブラウザを指定して、必要なpolyfillだけを注入する。副作用のない形でpolyfillを注入する。babel-polyfillsはこれら
babel/preset-env で polyfill するとビルドに失敗する問題の解決
この解決策を教えてくれた @about_hiroppyさん、ありがとうございます。 起きていた問題 少し前に Zenn にこういう質問を立てました。（こいつ質問サービスとして使ってやがる・・・） preset-env 経由で polyfill を入れると react が import されなくなる この質問は、IE 対応をするために @babel/preset-env と useBuiltin を使うと、ビルド時に react, react-dom の依存解決ができなくなってしまうものです。 IE 対応のための polyfill は babel を使うと簡単に導入できそうですが、 module.exports = { presets: [ [ "@babel/preset-env", { useBuiltIns: "usage", corejs: 3, }, ], [ "@babel/pr
Node.jsのネイティブES Modulesサポートが抱える問題を解決するBabelプラグインを書いた
babel-plugin-node-cjs-interop というパッケージを作ったのでその紹介です。 (GitHub) 何が問題か Node.jsのネイティブES ModulesサポートとBabelやTypeScriptのES Modulesサポートを併用したときに問題が起きます。 ESMとCJS JavaScriptには標準のモジュールシステム (ES Modules, ESM) がありますが、ESMの策定前に先だっていくつかのコミュニティー定義のモジュールシステムが存在していました。そのうちNode.jsを中心として使われていたのがCommonJS Modules (CJS) です。そのNode.js界隈でもESMへの移行が進んでいます。 移行にあたって問題になることのひとつが、ESMとCJSのエクスポートモデルの違いです。 ESMでは、モジュールは0個以上の名前つきエクスポートを定
Release v5.0.0 · facebook/create-react-app
v5.0.0 (2021-12-14) Create React App 5.0 is a major release with several new features and the latest version of all major dependencies. Thanks to all the maintainers and contributors who worked so hard on this release! 🙌 Highlights webpack 5 (#11201) Jest 27 (#11338) ESLint 8 (#11375) PostCSS 8 (#11121) Fast Refresh improvements and bug fixes (#11105) Support for Tailwind (#11717) Improved packag
Rust Is The Future of JavaScript Infrastructure
Rust is a fast, reliable, and memory-efficient programming language. It's been voted the most loved programming language six years in a row (survey). Created by Mozilla, it's now used at Facebook, Apple, Amazon, Microsoft, and Google for systems infrastructure, encryption, virtualization, and more low-level programming. Why is Rust now being used to replace parts of the JavaScript web ecosystem li
全ての道はRomeへ続くのか - これからのJavascript開発を考える
Romeとは 現代のJavascript開発には多くのツールチェーンが必要とされます。Babel,webpack,Jest,ESLint,Prettier,Typescriptなどを組み合わせて開発することが多く、さらにこれらの一部代替選としてesbuild,SWC,Viteなどのツールチェーンの選択肢が存在し、選択肢の多さやその組み合わせの複雑さに苦い思いをしたことがある方も少なくないのではないと思います。 こうした中で、新たに開発が進められているツールチェーン、Romeをご存知でしょうか？ Romeは先に挙げたように複数のツールチェーンを役割ごとに組み合わせて使うのではなく、1つのツールチェーンでこれら全ての役割を担ってしまおうという壮大な計画を持つツールチェーンです。 Romeは2020/03にFacebookより発表されました。現在は法人化され、yarnやBabelの生みの親である
GitHub Sponsors をはじめました
GitHub Sponsors をはじめました。 I've just started GitHub Sponsors. If you like my Open Source work, you can sponsor me on GitHub.https://t.co/1xiCsXDpzC — sosuke (@__sosukesuzuki) September 9, 2021 すでに4人の方に支援していただいています。ありがとうございます。 他の方にも支援していただけると嬉しいです。 Sponsor どのような OSS 活動をしているのか 主に JavaScript や TypeScript などのためのコードフォーマッター Prettier のメンテナーをやっています。 バグの修正、新しい機能の実装、リファクタリング、Issue のトリアージ、Pull Request のレビュー、リリ
Prettier 2.3 で TypeScript 4.3 をフォーマットする
{ "overrides": [ { "files": "*.ts", "options": { "parser": "babel-ts" } } ] } Configuration Overridesを使って、.tsファイルをフォーマットするときにbabel-tsパーサーを使うようにしています。 Prettier はデフォルトではtypescriptパーサーを使います。このtypescriptパーサーは、@typescript-eslint/typescript-estreeに依存しています。Prettier2.3 リリース時にはまだ@typescript-eslint/typescript-estreeは TypeScript 4.3 に対応していなかったので、Prettierはデフォルトのパーサーでは TypeScript 4.3 の新機能をフォーマットすることができません。 明示的
Ubie がスタートアップだからこそ OSS に寄付をする理由 | Yuku Kotani
いま働いている Ubie で OSS に寄付していくことを決め、まず手始めに JavaScript トランスパイラの Babel に$500 の寄付を行いました。日本のスタートアップが OSS に寄付をするのはまだあまり目にしないため、Ubie がスタートアップだからこそ OSS に寄付しようと考えた理由をご紹介します。 スタートアップにこそ OSS が必要 時間も体力もないスタートアップは、とにかく最速で事業を成長させなければならず、OSS が高速道路としてそれを支えてくれています。 これは極論ですが、OSS が全てなくなったとき、そのまま事業を続けていく自信が皆さんにはありますか？少なくとも僕にその自信はありません。体力のある大企業であれば内製する選択もできそうですが、スタートアップでは OSS なしにはビジネスを成し得ない場合が殆どではないでしょうか。 OSS が持続せずに困るのは、
Node.js v12のES Modulesと、Babel/TypeScriptの対応について - Qiita
本日は誕生日です。みなさんプレゼントありがとうございます。まだの方は急いでください。 あと年齢は聞かないでください。 はじめに Node.js v12で変更されるES Modulesの挙動についてと、Babelでの対応方法についての記事です。 10月に開催された関西Node学園 8時限目で発表した内容＋α（後日談含む）です。 対象者 ES Modules（import構文）は知ってるけどNode.js v12で何か変わったの？ 非対象者 v12での変更点もちゃんと知ってるし！ そういう強い子は、この記事本文はスルーしてもいいので最後にある「おまけ」だけでも見てください。 ES Modulesって何？ ていうかJavaScriptって何？ この記事のゴール Node.js v12におけるES Modulesの変更点について理解し、適切なコードを書けるようになる Babelを使っている場合は適
Dependency Managers Don’t Manage Your Dependencies
First published on May 5, 2021, updated on May 18, 2023 I promised to write about tech, so let’s start building our JavaScript infrastructure muscles. In the next several blog posts, I’ll cover introductory topics on dependency management, actionable tips for making your infrastructure better, and guides for building JavaScript infrastructure. We’ll slowly develop our shared understanding so we ca
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
インターン成果発表資料 / サイボウズ・フロントエンドエキスパートコース
GitHub - depcheck/depcheck: Check your npm module for unused dependencies
