Node.jsで型安全な環境変数を扱うスニペット
Node.js で型安全な環境変数を扱うスニペットを作りました。 next devのようなアプリケーションの起動、Playwright でのテストなどコマンドごとに渡したい環境変数のセットが異なるケースがあります。 この場合に環境変数をまとめたものを定義して、それをコマンドごとに読み込むセットを変えたいことがあります。 次のようにベタ書きしてもいいのですが、渡したい環境変数が増えると管理が大変になります。 NEXT_PUBLIC_LOCALHOST_URL=http://localhost:3000 NEXT_PUBLIC_API_URL=http://localhost:3001 NEXT_PUBLIC_IS_TEST_MODE=false FOO="bar" next dev そのため、.envのような環境変数をまとめたファイルを使いたくなります。 Node.js は--env-fil
Poku
🐷 What's Poku?A cross-platform test runner that brings the JavaScript essence back to testing. ⚡️ Quick Tutorials
JavaScript Runtimes (Node.js, Deno, Bun)
はじめに Bun 1.0 がリリースされたので、主要な3つの JavaScript Runtime のそれぞれの特徴をまとめる目的で書きました。 情報は 2023年09月時点のものです。また筆者はそれぞれの JavaScript Runtime に精通しているわけではないので、不足や間違った情報があるかもしれませんので、その点ご了承ください。不足や間違いがありましたら、コメントいただけると嬉しいです。 JavaScript Runtime とは JavaScript を実行する環境全般を指します。 この記事では、ブラウザを除く以下の3つの JavaScript Runtime を対象にしています。 Node.js Deno Bun JavaScript Runtime のシェア State of JavaScript 2022 の調査結果によると、Node.js が圧倒的なシェアを持ってい
Prettier's CLI: A Performance Deep Dive · Prettier
Hey, I'm Fabio and I've been contracted by the Prettier team to speed up Prettier's command line interface (CLI). In this post we'll take a look at the optimizations I've discovered, the process that lead to finding them, some exciting numbers comparing the current CLI with the new one, and some guesses about what could be optimized next. Installation The new work-in-progress CLI for Prettier has
corepack でモジュールごとに npm クライアントを指定する
tl;dr node 14.19.0 で npm のバージョンを明示的に切り替える corepack が入った package.json の packageManager フィールドで npm 自体のバージョンや yarn の使用するバージョンを指定できる 詳しくは https://zenn.dev/teppeis/articles/2021-05-corepack 現状の npm-cli 自体が corepack に対応してないので、有効にしたければ npm コマンド自体を corepack に移す必要がある 現時点で packageManager を指定するだけだとまだ他の環境で有効にならないが、将来的に npm と node の corepack 対応が行き渡った時点で段階的に有効になる。 もっと詳しく # 手元の node を v14.19.0 以上に更新する # 自分は nvm
Web アクセシビリティの検証ツール acot を作ってる - wadackel.me
はじめに タイトルにもある通り、最近 Web アクセシビリティ (以下アクセシビリティ) の検証ツールを作っています。この記事では作るにあたったモチベーションや、現時点での機能、今後の展望についてまとめます。 モチベーション アクセシビリティを評価しようとすると Lighthouse にも付随する axe のようなツールを用いることが多いと思います。axe は WCAG 2.0 や WCAG 2.1 に則った数多くのルールを持ち、アクセシビリティに関する問題発見を支援してくれます。Lighthouse 以外では、axe をモジュールとして使えることはもちろん、Chrome の Extension などからも実行可能で、ユースケースに合わせた柔軟な利用ができます。 ただ、検証精度はどうかというと少し物足りなさを感じる部分があります。例えば以下のような例です。 <div role="butto
Node.jsでUnhandled Rejectionsのときにexis statusが0となる問題を回避する
Node.jsでUnhandled Rejectionsが発生してprocessが終了すると、Exit Statusが0となる問題とその対策についてのメモです。 追記： Node.js 15+からUnhandle Rejectionが発生するとプロセスがExit Status 1で終了する動作がデフォルトとなりました Node.js v15ではunhandled rejectionでプロセスがエラー終了する 事前知識: Async FunctionはPromiseを返す関数定義です。 その辺について詳しくは次のサイトを読んでください。 JavaScript Promiseの本 非同期処理:コールバック/Promise/Async Function · JavaScript Primer #jsprimer 今回のサンプルコードは次のリポジトリにあります。 azu/unhandled-rej
2019年のWebAssembly事情 - Qiita
2年前に、「(Learn the Hard Way)nodejs-8でのWebAssembly自体を調べてみた」として、WebAssemblyについて記事にしました。 この記事は、2年前から変わった、2019年6月現在でのWebAssemblyの状況についてまとめたものです。 WAT: WebAssembly Text Format 2年前は、WebAssemblyのテキスト表現といえば、S式形式であり、フォーマット名は「WAST」と呼ばれていました。そして、ツールbinaryenの、wasm-as/wasm-disコマンドでバイナリ形式の.wasmファイルとテキスト形式の.wastファイルの変換を行いました。 2019年現在、WebAssemblyのテキスト表現は、「WebAssembly Text Format」通称WATとなっています。 http://webassembly.gith
TypeScriptで MessagePack encoder/decoder を実装した - Islands in the byte stream
npm install @msgpack/msgpack でインスコできます。NodeJS v12 でベンチマークしたかぎり、JSONと同程度の速度で、これまで最速といわれてきた msgpack-lite よりもさらに少しだけ高速です。 github.com もともとこのリポジトリには uupaaさんによる実装（tagged as classic) があったんですが、メンテされなくなって久しく npmjs.com にもリリースされていないという状況でした。 https://github.com/msgpack/msgpack-javascript/tree/classic その後kawanetさんが msgpack-lite を実装したのが2015年。これが2019年現在、もっとも週間ダウンロード数の多いMessagePack for JSの実装です。 msgpack-lite ピュアJa
Electron: Context Isolationの欠如を利用した任意コード実行 / Electron: Abusing the lack of context isolation - CureCon(ja)
ベルリンで開催されたCure53のイベント、CureConの資料です。
[メモ] JavaScriptエンジンを作る話 - Qiita
Rapidusの進捗を記していく。逐次更新 どんなJSエンジンを目指してるのか 自作ブラウザ(Naglfar)に組み込めるようなもの ↑でも当分はNodeJSみたいなのを目指すと思う (それ単体で使えるような物、という意味) JITに対応し、速い (LLVM使う?) 8/11追記: Tracing JITが部分的に動いた 課題 グローバル変数の呼び出し、遅い ネストした関数、実装してない 実装しました VMとVMのコード生成に関するコードのテストを書いてない (最近書き始めた) よく考えたら、字句解析器がコメントに対応してない 対応 参照渡しできない 進捗 日数は、Gitでコミットした日を数えてます。(7/1 7/2 7/5 とコミットしていたら、7/5は3日目としてカウント) 1日目 字句解析器がほぼ完成
![[メモ] JavaScriptエンジンを作る話 - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/46598b173ef0992637ef76538a4d9331ac2d727b/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCJUUzJTgzJUExJUUzJTgzJUEyJTVEJTIwSmF2YVNjcmlwdCVFMyU4MiVBOCVFMyU4MyVCMyVFMyU4MiVCOCVFMyU4MyVCMyVFMyU4MiU5MiVFNCVCRCU5QyVFMyU4MiU4QiVFOCVBOSVCMSZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZ0eHQtY29sb3I9JTIzMUUyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTU2JnM9OGUxOTQ4MTliMjk2OTdkMTAwZWQzYWY1OTQ3ZDU1OTQ%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDB1aW50MjU2X3QmdHh0LWNvbG9yPSUyMzFFMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT0zNiZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZzPTE4ZTA3ZGUyZDE1MTNhNDQ0MTgxNWQ5NzU4Njk2MDc5%26blend-x%3D142%26blend-y%3D486%26blend-mode%3Dnormal%26s%3Dc3248f30eb9509ace413608a642aa859)
Node.jsのビルトインモジュールに名前空間が使われるかもしれない - hiroppy's site
注意: これはまだ未定です。 他にいい案があれば、提案やコメントをしてほしいです。 "use strict"; const fs = require("@nodejs/fs"); // import fs from '@nodejs/fs'; console.log(fs.readFileSync(__filename, "utf8")); このように、@nodejsという名前空間でビルトインモジュールを保護する案が出ています。 もちろん、過去のコードに影響はありません。 PR は一旦、閉じられました。 WIP: tools: add core files to @nodejs namespace by cjihrig · Pull Request #20922 · nodejs/node This is probably not the ideal solution, but I wan
Node.js Performance 改善ガイド - from scratch
Node.js Performance 改善ガイド Memory の場合 メモリリークかどうかを特定する メモリリークではない場合 CPU の場合 どこの処理に時間がかかっているのかを確認する v8 simple profiler flame graph を取得する File の場合 大きなサイズのファイルをどうしても扱う時 Network の場合 keepalive を on にする その他: 全体的にパフォーマンスを改善するためにやること JIT が効いているかを確認する clusterが使えないか検討する C++ addons vs JavaScript libraries まとめ 参考資料 Node.js Performance 改善ガイド この記事は Node.js 2 Advent Calender の 5日目の記事です。 qiita.com Node.js のパフォーマンスに
ISUCON7予選のNode.js参考実装を担当させていただきました - Qiita
ISUCON7のNode.js版の参考実装の作成を担当させていただきました。 参加者のときとは全然別視点で、得られたことが沢山ありました。 Twitterでもつらつらと書いてたのですが、まとめた振り返りを書きたいと思います。 なお参考実装のリポジトリはこちらからご確認いただけます。 — ISUCON7 予選問題の公開と解説 : ISUCON公式Blog 自分のISUCON歴 ISUCON5, 6と二回参加し、どちらも予選敗退してます。 ちなみに過去二回ともGoでの挑戦で、Node.jsで挑んだことはありませんでした。 なぜやったか 自分は参加メンバーを集めきれなかっため、 Node.js版で参加したいという知り合いから「Node.js版に清き一票を！！」と推されて一票入れ、 あとは今年のISUCONには関わらず終わりかなと思っていました。 ISUCON参加予定者にアンケートです。PHP,
Google Apps Scriptの開発をモダンに行う方法 - Speee DEVELOPER BLOG
株式会社Speeeの山本です。皆様、こんにちは！ 今回ご紹介させていただくのは、Speeeで実践しているGoogle Apps Script(以下 GAS) を用いたモダンな開発手法についてです。この記事を通してGASって「便利だし使えるかも！」と思っていただければ幸いです。 Google Apps Scriptとは Google Apps Scriptは、言わずと知れたGoogleが提供するサーバサイドのスクリプト環境です。 基本的にはWebブラウザを通して開発を行います。 作業効率化に威力を発揮するGAS Speeeでは特に、管理部門の作業効率化でGASを使用しているケースが多く、例えば Slackの制限付きユーザを各種チャネルに招待するアプリケーション メーリングリストの文面生成を自動化するアプリケーション Speeeラウンジの使用状況を閲覧するアプリケーション など、様々な用途でG
Node学園26時限目まとめ - 技術探し
25時限目に引き続きオーガナイザーをしました about_hiroppy です。 今回の26時限目は、150人来ていただき本当に楽しく勉強になる時間でした。 改めてありがとうございました。 また、メルカリさんには会場整理、食事様々なことを手伝っていただき感謝します。ありがとうございました。 さて、今回の勉強会ですが、各フレームワークの話や型の話、低レイヤーのモジュールの話、 Chunked Encodingの話と結構コアな話が多い印象を受けました。 また懇親会では、古川さんからNode Collaboration Summit(Nodeのコアな人が集まるサミット(自分はこの回は行ってないです))やJSConf EU 2017で上がった議題の話がありました。(主にv8の最適化の話) 自分のwbepack3の発表を期待していた方はスミマセン(資料作ってなくて発表できなかったので。。。) 特に、
Stryker Mutator
Use code analysis and parallel test runner processes to speed things up.
npm-scripts で使える便利モジュールたち - Qiita
npm はパッケージ依存管理ツールであると同時に、便利なタスク・ランナーです。 本体はごく基礎的な機能だけを持ち、npm が管理するパッケージと Shell の力を組み合わせてタスクを定義します。「npm-scripts で利用する CLI コマンドは npm で管理できる」という分かりやすさが気に入っています。 npm-scripts には以下の特徴があります。 多くのツールが CLI を持っているためにラッパープラグインが不要です。Gulp ラッパー プラグインは非公式であることも多く、メンテナンスが継続するか不安な場合があります。 簡潔です。Gulp で書くと数十行だった処理が数行になるなんてこともよくあります。 複雑なことをするには向いていないです。 環境変数の扱いに難があります。 この記事では、私が npm-scripts を書くときによく利用している便利ツールたちを紹介します。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Node.js 2018 - Speaker Deck
GitHub - tj/n: Node version management
