winget、node、npmを使う前に、端末がどの実装を呼び、どの対象を読むかを確認してください。Node.jsのインストール方法を図解解説（初心者向け）の結論は「Node.jsは公式配布元またはWindows Package ManagerからLTSを入れ、node –versionとnpm –versionで検証します。Current版を安易に選ばず、案件のpackage.json、CI、利用frameworkの対応versionを先に確認し、複数案件を扱う場合はversion managerを検討します。」。初心者のWindows 11を中心に、開発案件の指定がなければLTS系を選ぶ環境で、未確認の変更を避けるための順番を示します。
既存node・npm・wingetの実体を記録する
Node.jsを導入する端末では、wingetの検索結果からOpenJSのLTSパッケージIDとインストール範囲を確認し、既存のnode、npm、PATHを記録します。導入後は新しいターミナルを開き、nodeとnpmの版、実行ファイルの所在、短いJavaScriptの終了コードを確認して、旧版とのPATH競合を切り分けます。
- SettingsのInstalled appsとwhere.exe nodeで既存導入を確認する
- package.jsonのengines、.nvmrc、CI定義で要求versionを調べる
- winget searchとwinget showでpackage ID、publisher、version、sourceを確認する
- 会社端末ではsoftware配布policyと管理者権限の要否を確認する
package IDをexact指定してLTSを導入する
既存環境を読み取り確認
where.exe node
where.exe npm
node --version
npm --version
winget list --id OpenJS.NodeJS.LTS
未導入ならwhereやversion確認はnonzeroで終わります。複数pathが出た場合は古いinstaller、Store、version managerが混在していないか、先にPATHの順序を整理します。
package情報を確認してLTSを導入
winget show --id OpenJS.NodeJS.LTS --exact
winget install --id OpenJS.NodeJS.LTS --exact --source winget最初のshowは読み取りです。publisherとsourceを確認後にinstallします。installは端末へ変更を加えるので、組織の承認済みsourceとmaintenance条件に従います。
新しいterminalで動作確認
node --version
npm --version
node -e "console.log(process.execPath); console.log(process.versions.node)"既に開いていたterminalは古いPATHを保持する場合があります。新しいPowerShellまたはcmdを開き、実行実体とversionを記録します。
最小projectで検証
mkdir node-check
cd node-check
npm init --yes
node -e "console.log('Node.js is ready')"書き込み可能な検証用directoryだけで実行します。業務projectでいきなりnpm installせず、lockfileやscriptが実行する内容をreviewしてから依存関係を扱います。
新しいterminalでPATHを再評価する
非公式download siteや検索広告のinstallerを使わず、package IDとpublisherを確認します。導入前に既存のglobal package一覧、npm設定、projectのlockfileを保管します。戻す場合はSettingsのInstalled appsまたは同じpackage managerでOpenJS.NodeJS.LTSをuninstallし、検証用projectだけを削除します。利用中projectのsourceやuser dataを消しません。version変更でCIと本番がずれる場合は、旧versionへ戻せるinstallerやversion managerの手順を先に用意します。
architectureとinstall scopeの差を確認する
Node.jsの偶数majorが常に同じsupport状態とは限らないため、固定観念でversionを決めず公式release情報と案件要件を照合します。npmはNode.jsと一緒に入りますがversion番号は別系列です。native addonのbuildには追加toolが必要な場合がありますが、すべての初心者がinstallerの追加tool optionを選ぶ必要はありません。必要性をpackageの説明から判断します。
複数Node実体によるversionずれを解消する
- 古い画面写真のversionをそのまま選ぶ
- CurrentとLTSを用途確認なしで入れる
- 既存NodeのPATH競合を残す
- 管理者terminalで全npm commandを実行する
- 知らないprojectのinstall scriptを確認せず動かす
最小projectでnpmとruntimeを試す
node、npmのversionだけでなくprocess.execPathで実体を確認し、npm config get prefixでglobal install先を記録します。最小scriptの終了コード0、terminal再起動後の同じ結果、IDE内terminalのPATHを確認します。proxy環境では証明書検証を無効化せず、組織のCAとproxy設定を管理者に確認します。
version・execPath・package testで導入を確定する
Windowsではwinget showでOpenJS.NodeJS.LTSのID・version・sourceを確認し、exact IDでinstallします。wingetの終了code 0と、別の新規terminalでwhere.exe node、node –version、npm –versionが同じinstall先を示すことを完了条件にします。
wingetの候補を確認してからinstallする
winget show --id OpenJS.NodeJS.LTS --exact
winget install --id OpenJS.NodeJS.LTS --exact --source wingetNodeの実体状態を三つの確認経路で判定する
- LTS実体を一意に確認：winget install成功後、新規sessionでnode/npmが見つかり最小scriptがstatus 0で実行される
- 既存版・対象なし：既に同versionならNo applicable upgrade等を変更不要として記録し、重複installerを追加しない
- winget・PATH error：source同意、network、installer hash、管理権限、PATH反映errorはwinget logを確認して再installを反復しない
古いterminalはPATH更新を受けない場合があります。where.exeで複数node.exeが出たら先頭だけを採用せず、Microsoft Store alias、旧MSI、version managerの順序を整理します。npmのglobal package権限を管理者常用で回避しません。
古いterminalと新しいterminalを比較する
where.exe node
node --version
npm --version
node -e "console.log(JSON.stringify({node:process.version,arch:process.arch}))"
未導入、同version、旧version併存、PATH未反映、offlineをtestします。package ID、installer source、node.exeの絶対path、version、architecture、最小projectのexit codeを保存します。
node –versionだけで終えず、process.execPathとnpmの応答を同じ新規terminalで確認します。where.exeが複数pathを返した場合は、利用中の実体を決めるまでproject作成へ進みません。
公式情報・参考資料
コメント