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 が挙げられていますが、この記事では「これら

はじめに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の挙動について整理する。 いきなり書かれても把握できないかもしれないが、一旦こ

はじめに Node.jsでパスワードや環境変数などを扱うとき、process.envを使いますよね。 process.envについてきちんと理解していなかったので整理しました。 環境変数とは お使いのPCがMac/Linuxの場合、下記bashコマンドでPCの環境変数が見れます。

リンクが無い学習コンテンツに関しては「Front Hacks」にて公開しております^^ 「約350本以上の解説動画(エクササイズの解説動画含む)」「スライド解説」「質問無制限」という内容で学習サポートをしております^^ (学習コンテンツは今後も随時追加予定) 前提 JavaScriptバックエンド編では「コマンドライン操作」や「バックエンドの基本知識(HTTPメソッドやステータスコードなど)」を知っている前提で解説します。 「コマンドライン操作」や「バックエンドの基本知識」をまだ学習していない方は以下の学習コンテンツから先に進めることをオススメします。 Node.JS入門 Node.JSとは Node.JSの環境を整える【インストールする】 Node.JSでJavaScriptファイルを実行する方法 【Node.JS】ファイルの分割・外部ファイル読み込みの方法 【エクササイズ】Node.J

Discord Botを無料で24/7(休まず常時稼働)させたいが、Vercelなどの無料サービスはその要件を満たさなかったので、AWSのEC2でやることにした。私と同じお金を使わずに何かをしたい人に向けてますので、感想等くださるとありがたいです。 特に誤った内容があると思われた方は、ぜひコメントをお願いいたします。 この記事でやること 【大目的】「無料」で、Node.jsのサーバを「爆速」で作る。 GitHubリポジトリのNode.jsのアプリを自動でAWS EC2インスタンスにデプロイする環境を作る。 本番環境のコードのブランチ(production)を作り、ソースコードがプッシュ(マージなど)されると、自動で最新のコードでNode.jsプロセスがスタートするようにする。 また、手動でデプロイ等の操作を実行することもでき、ここでアプリケーションの起動・停止を操作することもできる！！ ※

Node.js is an open-source, cross-platform JavaScript run-time environment built on Chrome’s V8 JavaScript engine that executes JavaScript code outside a browser.

創業4年、当ブログで変わらず愛されてきたGatsby v2 このブログをたてたのは、私がまだエンジニアになる前、2020年のことだった。 当時の私は、Reactもよく分かっていなかったし、GraphQLなんてまるで理解していなかった。 理解していなかったくせに、なんとなく流行の技術が含まれてそうだということを察知したミーハー根性により、Gatsbyを使ってブログをたてたのであった。 お察しの通り、エンジニア経験もない人間がたてたnodejs環境がまともに更新されるわけもなく、インストール当初のパッケージのままずっと運用されてきた次第である。 Apple Siliconでビルドが通らない 時は流れ、2023年に私はM1 MacBook Proを手に入れた。 すると、dev serverがそもそも立ち上がらなくなった。しかし、当時の私はそこそこ忙しい生活を送っていたのでブログを書く時間もあまり

「3時間でNode.jsでREST APIを作る」ためのチュートリアルブックです。気軽に手にとってもらうために分量を少なめにしました。初心者から上級者まで学びのある内容になっています。チートシートとしても活用できます。

追記: 2023-11-19 corepack v0.20.0 にて、CLI のコマンド体系が一新されて多少わかりやすくなりました (PR#291)。新しいコマンドは README を参照。 追記: 2022-02-03 Node.js v14.19.0 に corepack が標準バンドルされました。 corepack がバンドルされていない Node.js v12 系は 2022-04-30 に EOL を迎えるので、あと 3 ヶ月もすればアクティブな Node.js 環境には必ず corepack が揃っているという状態になりますね。引き続き experimental ステータスのままではありますが。 追記: 2021-09-08 Node.js v16.9.0 で corepack が標準バンドルされました。まだ experimental 扱いですが。 デフォルトでは yarn も

複数のリポジトリで共有する node パッケージを、パブリックな npm レジストリではなく GitHub Packages の npm レジストリに公開して、 GitHub Organization 内でのみ利用可能なパッケージとして扱う手順を、社内共有用にまとめていきます。 本記事の内容は、以下の公式ドキュメントを読めばだいたい分かります。 背景 マネーフォワード クラウドシリーズのデザインシステムを構築しようとしており、複数のプロダクトで共通して利用できる汎用的な UI コンポーネントを揃えたライブラリを各プロダクト向けに公開したい。検証段階なので、一旦 org 内に限定した状態で利用したい。 GitHub Packages とは Introduction to GitHub Packages - GitHub Docs より GitHub Packages is a softwar

2023-01-20 NestJSを用いたWebAPIサーバーの開発と、仕様書作成/APIテストの効率化 NestJS Swagger API Testing Dredd はじめに 私たちのチームでは、新しく作成するREST APIサーバーの開発にNestJS、API仕様書のフォーマットにOpenAPI(Swagger)を採用しました。NestJSでは、組み込みのモジュールを利用することにより、OpenAPI仕様書を容易に作成することが可能です。 また、APIテストフレームワークにDreddを用いることで、実装がOpenAPI仕様書通りに動いているかどうかを自動で確認することができます。この記事では、NestJSとDreddに関しての説明や利点、またサンプルコードを用いて実際にAPIサーバー構築・OpenAPI仕様書作成・APIテストまでの一連の流れを紹介していきます。 この記事の対象者

皆さんnpmパッケージのバージョンを上げるときにハマって依存地獄から抜けられなかったことはありませんか？ 私はあります。 複雑怪奇な依存関係を調べてみようとnode_modulesを覗いてみて、そのカオスっぷりに臭いものに蓋をしたことはありませんか？ 私はあります。 そこでnode_modules以下について調べてみたのですが、node_modulesにどんな問題点があって、npmやyarn, pnpmは何を目指していたのか時系列順に紐解いた方がわかりやすいことに気づきました。 ここでは初期のnpmが抱えていた問題から今に至るまでを順を追って説明します。 するとnode_modulesの仕組みの他に、各パッケージマネージャの方針の違いが見えてくるはずです。 初期の頃のnpm (~2015年以前) この頃はシンプルで、依存関係はそのままnode_modulesのディレクトリ構造に反映されてい

Ubie では、創業当初から Server-Side Kotlin を推進してきましたが、全社的な技術選定を再度行い、これからは Go と Node.js を中心とすることにしました。 本記事では、Go と Node.js を選定した理由や、それを普及させる取り組み、そして選定の流れを紹介します。 経緯 これまで Ubie では技術スタックを発散させてきていて、現在は Kotlin、Go、Node.js、Ruby、Python のバックエンドサービスが動いています。以前は新規開発が多く、それぞれに携わるメンバーが技術選定をすることにより、最大瞬間風速を出せるなどのメリットがありました。しかし、現在では弊害が目立ってきています。 まず、事業成長に伴って運用の重要性が増しています。人材が潤沢とは言えないスタートアップにおいて、様々な技術スタックを安定運用することはコストが高すぎると感じています

はじめにSHIFT DAAE の shinagawa です。表題の通りNode.jsで作成したコンテナのイメージサイズの軽量化に挑戦しました。 背景近年の多様化・高速化するビジネスに対応するITシステムの構築を実現する「クラウドネイティブ」の構成要素の一つとして 「コンテナ」という仮想化技術が存在し、当部門でも活用を進めております。 このコンテナイメージを作成するにはアプリケーションコードやライブラリ・モジュールなどの依存物、ランタイム等を1つのイメージとして組み立てて作成しますが、 この構成要素が増えるとイメージサイズが肥大化し保管時のストレージのコストの増加やイメージの転送、環境への展開に時間がかかることになります。 従ってイメージのサイズを削減することは、これらの点を改善することにつながります。 ここではネット上で紹介されている、あらゆる打ち手を組み合わせてコンテナイメージの軽量化に

どうも、つよぽん(@tsuyopon_xyz)です！ 今回の記事の内容は、動画編集の「ジャンプカット（別名 : ジェットカット）」をNode.jsを使って自動化する方法を解説します。 この記事を読んでわかるようこと 今回の記事では主に以下の2つを話していきます。 今回紹介するジャンプカットツールの効果 Node.jsを使った動画編集のジャンプカットツールの実装方法 自動ジャンプカット（ジェットカット）前と後の違い まずは自動ジャンプカットする前の動画の様子から観ていきます。 以下の動画では間を開けるようにしゃべっています。 次に、自動ジャンプカットした動画を観ていきましょう。 以下の動画は先ほどの動画を、今回作成した自動ジャンプカットプログラムを用いて空白部分をカットしたものになります。 それぞれの動画を比較してみると、いい感じにカットできているのがわかるかと思います。 自動ジャンプカット

IE終了により、webpackやbabelを使う必要がなくなるのか、フロントエンドからビルドステップを完全に消し去ることはできるのか。 そもそもなぜフロントエンドを「ビルド」していたのか そもそもなぜwebpackやbabelを使ってJavaScriptをバンドル（1ファイルにまとめる）していたのか 1. HTTP/1.1とモジュールシステムの相性の悪さ ブラウザにはES Moduleというモジュールシステムが導入されています。これはimport文で他のファイルを読み込むことができるシステムです。 HTTP/1.1については、ブラウザ側で同時接続数制限があります。これは、ファイルを多数読み込む必要があるES Modulesには不向きでした。 2. ブラウザのES Module対応率の低さ ES ModulesはIE非対応です。開発するWebサイトがIEをターゲットにしたい場合、ES Mod

例えばmain.tsというスクリプトに対して、ファイルの読み取りだけを許可したい場合は、以下のようにコマンドを実行します。 $ deno run --allow-read main.ts このときmain.tsプログラムはファイルの読み取りだけが可能になるため、ファイルの書き込みやネットワークアクセスをするとPermissionErrorによる実行時エラーになります。 なお、実行時にフラグを何も与えなければ、どの権限も持っていない状態になります。 各フラグにはパラメータを指定でき、例えば次のように実行すると/home/userディレクトリの読み込みだけが許可されます（--allow-writeフラグも同様）。 $ deno run --allow-read=/home/user main.ts また、--allow-netを次のように指定すると、特定のドメインとポートだけのアクセスを許可で

Intro ちょうどタコピーの原罪が流行ってるのでこのタイトルにしたけど結構気に入ってる。 d.potato4d.me この話を読んでの感想とここまで大きくなった Node.js の振り返りをしようと思う。 どんなプログラミング言語であってもみんなから使ってもらって開発者をハッピーにしたいと思ってる。ただ最初は良かったと思ってた機能がなんか古臭くなったり、他にクールな機能を持ったものが登場したことによって徐々に飽きられていき、最終的に他の言語に乗り換えられる。 まぁどんな言語も同じだと思う。C言語だって生まれた当初はすごくクールでみんなをハッピーにしてた。今丁度「戦うプログラマー」を読んでるが、C++が出てきて、周りのエンジニアが C++ を使おうとするシーンが出てくる。そこで、「あんなの使って何が良いんだ、Cで十分だろ」とWindows NT 開発リーダーのデーブカトラーが言ってたりする

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

かれこれ 5 年くらい趣味開発で npm-scripts を書き続けている。長年書き続けているとノウハウが蓄積されてきて、「こう書くとスッキリする」「迷いがなくなる」「後から拡張したくなった時に、簡単に拡張できる」みたいな書き方が身についてきた。自分の型、あるいは手癖のようなものだと思う。 せっかくなので、id:mizdra の今の npm-scripts を書く時の手癖を書き連ねてみる。 基本形 { "scripts": { "build": "webpack --mode production", "dev": "webpack-dev-server --mode development", "lint": "eslint .", "test": "jest" } } 一番シンプルな npm-scripts を書く時のパターン。以下の 4 つの script を登録している。 buil