Node.js の進化に伴い不要となったかもしれないパッケージたち
tl;dr はじめに 2024 年の 4 月 24 日に Node.js 22 がリリースされました。ESM を 条件付きで require する機能や、--run フラグによる npm スクリプトのパフォーマンス改善などが v22 で追加され、2009 年に Ryan Dahl が Node.js をリリースしてから 15 年が経つ今も、Node.js は進化を続けています[1]。 こうして Node.js 自身が強化されていくにつれ、以前はサードパーティーのパッケージを使用して実現することが一般的であった機能が Node.js のみで実現可能となり、当該パッケージが不要となるような場合があります。冒頭に引用した Ben Holmes の動画では、そのように不要となったパッケージとして dotenv node-fetch chalk mocha が挙げられていますが、この記事では「これら
Node.js — Node.js 22 is now available!
We're excited to announce the release of Node.js 22! Highlights include require()ing ES modules, a WebSocket client, updates of the V8 JavaScript engine, and more! Node.js 22 will enter long-term support (LTS) in October, but until then, it will be the "Current" release for the next six months. We encourage you to explore the new features and benefits offered by this latest release and evaluate th
Node.js + TypeScriptのモジュールを整理してみる
はじめにlink 最近受けるNode.js + TypeScript環境の相談の中で、CommonJSやECMAScript Modulesのあたりで落とし穴にはまっている人が多いという事に気づいた。 Node.jsは歴史的にCommonJSとECMAScript Modules（以後ESMと表記）がどうしても入り乱れる環境にあり、これにTypeScriptのモジュールが加わると組み合わせでさらに複雑度が増すのが現状である。 説明する際に口頭より整理した文章が欲しいと思ったので記事にする。 以下のリポジトリで検証コードを管理している。 https://github.com/koh110/module_test Node.jsモジュールチェックシートlink まず最初にNode.jsにおけるCommonJSとESMの挙動について整理する。 いきなり書かれても把握できないかもしれないが、一旦こ
Deno first でやっていく
去年末ぐらいから Deno を使う割合がグッと増えてきた。最近のJS関連は7割ぐらい deno 環境の VSCode でコードを書いている気がする。 今回はいくつかの実例を示しながら、実際に Deno 使えるじゃんというイメージを持ってもらうためのユースケースを紹介していく。 というか、 deno が普及してくれないと、自分が作ったツールの紹介を全部 deno のインストールから書かないといけなくなる。みんなインストールしといて。 最初に: なぜ Deno を使いたいか 一番の問題点、Node は新しいプロジェクトを一式整えるための手間が非常に重い。 とくに ts で書いたものを他の環境に渡すための方法が未だにしんどい。ある環境で動いたコードをそのままコピーしても、プロジェクト設定の非互換を踏む可能性が非常に高い。 deno にそういう側面がないとは言わないが、非常に少ない。とくに TS
あたらしいフロントエンド開発ツール「Nue」 | DevelopersIO
About Nue 鵺（ぬえ）。 猿の顔、タヌキの体、蛇の尻尾、虎の脚を持つ妖怪です。 日本人ならNueと聞いた場合、思い浮かべるのは↑かと思うのですが、 これは先日リリースされた、フロントエンド開発ツールセットです。 ＊「Nue」はドイツ語で、「新しい」という意味だそうな *「Nue」はドイツ語の「neu」に由来しており、英語で「新しい」という意味だそうな 開発者はTero Piirainenという方で、 現在彼１人で開発しています。 ここを見ると、「Webの開発方法が変わるかも」と かなりすごいことが書いてありますが、どんなものなのか見ていきましょう。 Nueとはなんなのか？ 公式を見ると、↓のようなことを言っています。 React、Vue、Next.js、Vite、Astroの代わりになる NueはSPAMPAの両方に対するサポートを備えたWebアプリケーションビルダーである Nue
Node v20.6.0 (Current) | Node.js
Notable changes built-in .env file support Starting from Node.js v20.6.0, Node.js supports .env files for configuring environment variables. Your configuration file should follow the INI file format, with each line containing a key-value pair for an environment variable. To initialize your Node.js application with predefined configurations, use the following CLI command: node --env-file=config.env
node_modulesの問題点とその歴史 npm, yarnとpnpm
皆さんnpmパッケージのバージョンを上げるときにハマって依存地獄から抜けられなかったことはありませんか？ 私はあります。 複雑怪奇な依存関係を調べてみようとnode_modulesを覗いてみて、そのカオスっぷりに臭いものに蓋をしたことはありませんか？ 私はあります。 そこでnode_modules以下について調べてみたのですが、node_modulesにどんな問題点があって、npmやyarn, pnpmは何を目指していたのか時系列順に紐解いた方がわかりやすいことに気づきました。 ここでは初期のnpmが抱えていた問題から今に至るまでを順を追って説明します。 するとnode_modulesの仕組みの他に、各パッケージマネージャの方針の違いが見えてくるはずです。 初期の頃のnpm (~2015年以前) この頃はシンプルで、依存関係はそのままnode_modulesのディレクトリ構造に反映されてい
CommonJSからES Modulesへの移行する方法。トップダウンかボトムアップか
Secretlint v7でCommonJS からES Modulesへの移行を行いました。 Secretlint v7.0.0をリリースしました。Pure ESMへの書き直し この記事では、CommonJS(CJS)からES Modules(ESM)への移行を行った経緯と、移行する方法について紹介します。 CJSからESMへの移行は、率直に言えば単調な作業で、メリットが見えにくい作業です。 しかし、将来的にCJSよりもESMが主流になることは間違いないので、移行することは必要です。 移行の作業は、移行方法が決まれば大部分は機械的な書き換えが可能です。 では、実際にどうやって移行したのかを紹介します。 ESMへの移行の影響は依存元へと連鎖する Secretlintのリポジトリはmonorepoになっていて、だいたい40コぐらいのパッケージが含まれています。 そしてパッケージ間で依存関係があ
アプリケーションコードに変更を加えないNode.js Native ESMへの移行
LINE株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。 LINEヤフー Tech Blog はじめに こんにちは。フロントエンド開発センター(UIT) Front-end Dev.9チームの鴻巣(@kazushikonosu)です。LINEスキマニおよびLINE Creators Marketのフロントエンド開発を担当しています。 LINEスキマニのフロントエンドチームでは、React/TypeScript製のWebアプリを開発しています。主にクライアントサイド向けのコードを扱っていますが、SSRのため同じリポジトリ内でNode.jsを使って実行されるTypeScriptコードも扱っています。クライアントサイドのモジュールバンドラとして長らくwebpackが使われていましたが、webpackを使い続けることでチームの
Node.js 14から18へアップデートする方法について
Corepackを使ってNode.jsをアップデートする ⬆️⬆️というタイトルで、Node.js 14からNode.js 18へのアップデートする方法について話した。 Node.js 14は4月末でEOLで、Node.js 18までアップデートする必要があるけど、npmの変更が混ざって大変です。 Corepackを使うことで、Node.jsとnpmのアップデートを同時にやらなくても良くなり、問題を分割して対応できます！ Corepackを使ってNode.jsをアップデートする ⬆️⬆️https://t.co/mRHsBcYbpn pic.twitter.com/HiiCe7c5YE — azu (@azu_re) April 28, 2023 スライド: Corepackを使ってNode.jsをアップデートする ⬆️⬆️ Note: Node.js 14は2023-04-30でEOLで
Corepackを使ってNode.jsをアップデートする ⬆️⬆️
Corepackを使ってNode.jsをアップデートする ⬆️⬆️ 自己紹介 Name : azu Twitter : @azu_re Website: Web scratch, JSer.info [.background-color: #FFFFFFF] Node.js 14は2023年4月でEOL Node.js 14.xは2023-04-30、Node.js 16.xは2023-09-11でEOL(End Of Life) 2023年10月からはNode.js 18と20のみがLTSとしてサポートされるバージョンとなる https://github.com/nodejs/release#release-schedule サマリ Node.jsのバージョンアップは面倒だけど ほとんどのBREAKING CHANGEはライブラリにある npmのバージョンアップは面倒 npm 6とnpm
Node.js v20 の主な変更点 - 別にしんどくないブログ
2023 年 4 月 18 日にリリースされた Node.js v20 の主な変更点を紹介します。 nodejs.org ファイルのアクセスやプロセスの起動を制限する新しいパーミッションモデル (experimental) --allow-fs-read でファイルの読み込みを許可する --allow-fs-write によるファイル書き込み許可 --allow-child-process による child_process の許可 --allow-worker による Worker Threads の許可 Permission Model の参考記事 V8 11.3 による新しい JavaScript の機能 テストランナー（node:test）が stable に昇格 Single Executable Application JSON の config を使った Blob が必要に
Node.js — Node v20.0.0 (Current)
Notable Changes Permission Model Node.js now has an experimental feature called the Permission Model. It allows developers to restrict access to specific resources during program execution, such as file system operations, child process spawning, and worker thread creation. The API exists behind a flag --experimental-permission which when enabled will restrict access to all available permissions. B
Node.jsとJavaScriptアプリを単一の実行ファイルにする「Single Executable Applications」機能、Node.js 19.7.0で実験的機能として搭載
2月21日にリリースされたNode.jsの最新バージョン「Node.js 19.7.0」で、Node.jsとJavaScriptアプリケーションを単一の実行ファイルにパッケージングする新機能「Single Executable Applications」が実験的機能として搭載されました。 一般にNode.jsのアプリケーションをデプロイするには、Node.jsのインストールや環境設定をするところから始めなければなりません。 今回新しく実験的に搭載されたSingle Executable Applications機能を使うと、そのまま実行可能な単一の実行ファイルを作ることができるため、それを配置するだけで簡単にデプロイができるようになる見通しです。 Single Executable Applicationsでは、postjectと呼ばれる新しいコマンドが用意されます。これを用いてNode.
分散型SNS「Misskey」、それを支える技術スタック | gihyo.jp
本連載は分散型マイクロブログ用ソフトウェアMisskeyの開発に関する紹介と、関連するWeb技術について解説を行っていきます。第1回はMisskey、ひいては分散型SNSの簡単な紹介とその内部実装の概略を説明します。 はじめまして！ はじめまして、Misskey（みすきー）のプロジェクトリーダーをしている、しゅいろ（@syuilo）です！ この度連載の機会をいただきましたので、ちょっと仰々しい気もしますが「Misskey & Webテクノロジー最前線」と題して、今後Misskeyやそれに関わる最新のWeb技術について解説をしていく予定です。 今回はMisskey、ひいては分散型SNSの簡単な紹介とその内部実装の概略を説明します。 対象読者は、後半の実装解説の部分においてはある程度のWeb開発の知識がある人を想定しています。 Misskeyとは、そして分散型とは Misskeyは、オープン
Node.js Docker baseイメージには alpine < distroless < ubuntu+slim 構成がよさそう
Node.js Docker baseイメージには alpine < distroless < ubuntu+slim 構成がよさそう はじめに この記事は、DockerCon 2022 で発表された Bret Fisher の "Node.js Rocks in Docker, DockerCon 2022 Edition" を参考にしています。 base イメージの選択肢に関する話は、動画の前半一部分だけですが、他にも Node.js で Dockerfile を書く時のベストプラクティスが数多くまとまっているので、是非チェックしてみてください。 node:alpine イメージを使わない base イメージサイズを小さく保ちたい、という点で気軽に利用される事が多い alpine イメージですが、Official の README には下記の記載があります。 This variant
NestJS製GraphQLサーバの起動が遅かったので調査した話 - もうずっといなかぐらし
こんにちは、かたいなかです。 最近、NestJS製のGraphQLサーバでのSchemaからのTypescriptファイルの生成が遅い問題を調査する機会がありました。 今回の記事では、ツールの使い方等の自分への備忘録を兼ねて、どのように問題に取り組んだかを記事にして紹介します。 TL;DR 高速化するならまずは計測から。計測によるボトルネック特定が最優先。 フレームグラフが遅い処理を特定するのに超便利。Node.jsなら0xがフレームグラフ生成に便利。 @nestjs/graphql でGraphQLのスキーマからTypescriptのファイルを生成する処理が速くなった。 経緯 最近関わった案件では、BFFとしてNestJS製のGraphQLサーバをスキーマファーストで使用していました。GraphQLによるスキーマファーストな開発の恩恵は日々感じているものの、サーバの起動時や再コンパイルの
Electronライクな新フレームワーク「Gluon」登場。Chromium内蔵せずWebブラウザを利用、Node.jsだけでなくDenoとBunにも対応
デスクトップアプリケーションの開発を、JavaScriptなどのWebテクノロジーで可能にするフレームワークとして知られるのがElectronフレームワークです。 このElectronのようなフレームワークが新たに登場しました。「Gluon」です。 Electronがアプリケーション基盤としてNode.jsとChromiumをバンドルするのに対して、GluonはOSにインストールされているWebブラウザを用いるのが大きな特長です。 Google ChromeのようなChromiumベースのWebブラウザだけでなく、Firefoxにも対応作業が進められており、最新のバージョン0.11ではFirefoxでの安定度が向上しました。 Node.jsをバンドルする点はElectronと同じですが、Node.jsの代わりにDenoやBunを利用することにも実験的に対応しています。 Gluonは主にCh
Node.js にプロセスレベルの Permission が入りそうな話 - from scratch
Node.js の Permission についての解説を行います。 Node.js に Permission 機能が入りそう。 すでに PR が出されており、 land も間近です。おそらく次かその次くらいのリリースで入ることになるでしょう。 github.com おそらく初期リリースでは experimental flag を付けた上で、 fs, child_process, worker のパーミッションを許可するかどうかに留まり、 net, env などのパーミッションは今後になるでしょう。 以下の方法で利用します。 // filesystemの読み書きを許可する $ node --experimental-permission --allow-fs foo.mjs --allow-fs ファイルシステムの読み書きを行えるようにする --allow-fs-read= に記載のファイ
Ubie は Go と Node.js の会社になります
Ubie では、創業当初から Server-Side Kotlin を推進してきましたが、全社的な技術選定を再度行い、これからは Go と Node.js を中心とすることにしました。 本記事では、Go と Node.js を選定した理由や、それを普及させる取り組み、そして選定の流れを紹介します。 経緯 これまで Ubie では技術スタックを発散させてきていて、現在は Kotlin、Go、Node.js、Ruby、Python のバックエンドサービスが動いています。以前は新規開発が多く、それぞれに携わるメンバーが技術選定をすることにより、最大瞬間風速を出せるなどのメリットがありました。しかし、現在では弊害が目立ってきています。 まず、事業成長に伴って運用の重要性が増しています。人材が潤沢とは言えないスタートアップにおいて、様々な技術スタックを安定運用することはコストが高すぎると感じています
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
