はてなブックマーク

といいつつも、この機能自体は要オプションで v9.7 からありましたが、 v10 でオプション不要になったので、 GA の気持ちで紹介します。 結論 pnpm v10 以上がローカルにインストールされていれば、 packageManager field に pnpm が指定されているプロジェクトでは、そのプロジェクトの pnpm を使うようになります。 ただし、その pnpm 自体はどこかしらにインストールされている必要があり、一般的にはプロジェクトの devDependencies にインストールするものかと思われます。 やるべきこと ローカルの pnpm を v10 以上にする。 プロジェクトの devDependencies に、使いたいバージョンの pnpm をインストールする プロジェクトの packageManager field に 2 と同じバージョンの pnpm を定義す

mise はミーズと読みます。 mise とは *env や *vm が担っていた言語環境(コンパイラ・インタプリタ)のバージョンを管理するツールです。 rbenv や nvm のように単一言語に対するサポートではなく、標準で Go、 Node.js、 Python などの複数の言語に対応しています。 類似のソフトウェアに asdf が存在しますが、 mise はその精神的後継となっています。asdf が shell で書かれていたのに対し、 mise は rust で実装されており、起動速度も asdf と比べて格段に早くなっています。 mise は The front-end to your dev env. と自称しており、上記の言語環境のみならず、アウトオブボックスで使用できる複数の開発向けの機能を提供しているので、本稿で紹介します。 言語環境の用意 mise が提供する言語環境は

mise とは 言語環境の管理は *env や *vm を超えて、 mise へ という記事を書いたので詳しくはこちらをご参照ください。 簡単にいうと多言語対応の言語環境マネージャで(もっと多機能なのですが)、npm をバックエンドに node 製の cli まで管理できる、というものです。 つまり、 yarn や pnpm もグローバルでバージョン管理できるということになります。 似た機能を持つものに volta が存在しますが、筆者の主観だと mise の方が安定した挙動をしており、高速です。 mise の npm backend 機能 mise では npm をバックエンドにして npm library な cli を管理する、という機能があります。(執筆現在 Experimental です) https://mise.jdx.dev/dev-tools/backends/ 例えば、

Result 型 (類似するものとして Either Monad の方が有名かもしれません) を導入する場合、アプリケーション全体の設計を変えたり、全箇所を書き換える必要はありません。 neverthrow は部分的に使用でき影響範囲も閉じるので、局所的に使い始めることができます。 (Rust のような) Result 型 とは ざっくり言うと関数の処理の結果と成否を 1 つの型 Result<T, E> で表したものです。(T は期待する結果の型、 E はエラーを表現する型) 筆者は詳しくはないのですが、 Haskell 等にある Either<L, R> とは厳密には違うようです(Either は両方の値が使用可能であることを前提としている？) 参考: Rust ではなぜ、Either 型ではなく Result 型を採用しているのか neverthrow とは TypeScript で

背景 neovim で会社の先輩からもらった vimrc を 7 年くらい継ぎ足し継ぎ足しで使っているぐちゃぐちゃの init.vim と、どこでどう動いているか把握していないプラグインも混ざっている dein.toml を、 init.lua & lazy.nvim への移行に合わせて整理した。 lazy.nvim とは 最近急速に注目を浴びているらしい Lua 製(かつ Lua 記述)のプラグインマネージャ。 README を見る限りだと init.lua でのセットアップしか書いていない。vim script に翻訳すれば init.vim でも動くのかもしれないが、変な橋を渡って消耗したくないので今回は素直に init.lua 化をしている。 init.lua の記述 $XDF_CONFIG_HOME/nvim に init.lua ファイルを作成する。 init.vim と両方存

最新の WSL2 ではネットワークのブリッジモードがサポートされており、有効化するとホストである Windows へのポートフォワードはそのままに、外部へ直接接続する(ルータから DHCP で IP を振り分けてもらえる)ようになり、つまり LAN からアクセス可能となる。 ただしこの方法は現在 Professional Edition でないと動作しない。 (Hyper-V を操作する必要がある。Hyper-V 無しでもブリッジの設定ができるようになると、 Home でも動作すると思われる。 手順 Hyper-V で外部との通信用の仮想スイッチを作成する WSL を有効化した際に標準で存在するスイッチはいずれも ホスト(Windows) <-> ゲスト(WSL) の通信のためのものであるため、外部と通信する仮想スイッチを設定する。 仮想スイッチマネージャを開き、新しい仮想ネットワークスイ

自宅の nerdctl + containerd 環境を rootless にした際のトラブル対応だが、 docker の場合もおおよそ似たものだろうと思う。 rootless とは 通常のままだと docker / nerdctl は root 権限で動作してしまう。 sudo usermod -aG docker <USER> などして sudo 不要にしていても実際には sudo しているのと同じことである。 rootless にすると各ユーザごとにコンテナが起動することになる。ホストマシンでの各ユーザの権限を最高としてコンテナ内では root として扱うことができるため、例えば volume mount の中にホストマシンで root 権限を要するファイルがあった場合、コンテナからは触ることができない。 これにより脆弱性が突かれた場合でも root 権限による操作を防ぐことができる

並列実行した Promise で throw されても全てハンドルしたいときの方法(allSettled, finally, etc...) 要諦 以下のアプローチが主な解決方法となるだろう Promise.allSettled で全ての Promise の解決を待ち、解決された値を用いて処理を行う(動機的後処理) Promise.all に渡した各処理に Promise.prototype.{then,catch,finally} を定義し、適切に後処理を行う(非同期的後処理) 各処理を中断可能に実装し、 catch された時点で中断命令を送る(中断) Thanks to @uhyo_ ハンドルしたいだけなら allSettled である必要はない旨のご指摘を頂いたため、本文趣旨を変更しました。 詳細 Promise.all の返却する Promise は何かしら 1 つでも throw