nazolabo

Webエンジニアのnazoさんのブログです。お仕事募集中です。 https://nazo.dev/ Zennにも一部転載しています

ent ( entgo.io/ent ) で ULID を使う

ent では UUID 型がデフォルトでサポートされているのですが、それとは別に ULID を使う方法を解説します。

ULID の実装は https://github.com/oklog/ulid を使用します。

ent の UUID 型は、driver.Valuer Interface を利用して値を取得しますが、 oklog/ulid の Value() の実装がバイナリを返却するようになっているため、このままでは可読性が悪いです。 Value() が String を返すようにした ULID 型を新たに定義するのが良いでしょう。そのようにすると、他の interface も実装する必要があります。

結論から言うと https://github.com/ent/contrib/blob/6623819401500db45747a2419172963217cef619/entgql/internal/todopulid/ent/schema/pulid/pulid.go にそのものの実装があります1。この実装はライブラリ化されているものではない( internal )ので、そのままコピペして利用するのが良いでしょう。

使用する場合には以下のようになります。

// Fields of the User.
func (User) Fields() []ent.Field {
    return []ent.Field{
        field.String("id").
            GoType(pulid.ID("")).
            DefaultFunc(func() pulid.ID { return pulid.MustNew("US") }),
        field.Int("age").Positive(),
        field.String("name").Default("unknown"),
    }
}

prefixが不要な場合はprefixの部分を削ってしまうのが良いかと思います。

このままの実装でもう少し手軽に書きたい場合は、同リポジトリmixin が存在しますので、これを持ち出すと良いと思います。

ent は各フィールドを固有の型にできますので、例えば上記例で ID を UserID 型にしたい場合は以下のようになります。

type UserID pulid.ID

// Fields of the User.
func (User) Fields() []ent.Field {
    return []ent.Field{
        field.String("id").
            GoType(UserID("")).
            DefaultFunc(func() UserID { return UserID(pulid.MustNew("US")) }),
        field.Int("age").Positive(),
        field.String("name").Default("unknown"),
    }
}

  1. https://github.com/tmc/pulid のように見えるのですが、こちらは Value() はバイナリを返すようです。

Infrastructure as Codeは最初からやったほうがいい

最近不慣れな GCP を触ることがあったのですが、最初から Terraform で書くようにしたほうが楽だったので、それについて解説しようと思います。

Web のコンソールを触るのが怖い

他のサービスが同居しているアカウントでインフラを操作すると、他のサービスに影響を与えてしまうのでは…という不安があります。関係のないサービスは別アカウントにするというのがベストプラクティスですが、様々な事情によりそれができない場合もあります。

最初から IaC で触っていれば、コードで生成したインフラ以外を触ることがなく、削除する時も間違えることがなく削除することができ、何度も作り直して試すことが容易になります。

手順を覚えられない

Webのコンソールでも、コマンドラインツールでも同様ですが、作業した内容を記録しておく必要があります。記録していない場合、同じ環境を再現することができません。

最初からコード化をしていれば、手順を覚えておく必要もありません。

必要な依存関係を最初から教えてくれる

コンソールで触っていると、どのサービスとどのサービスが繋がっているかというのがわかりにくいですが、例えば Terraform では必須パラメーターとして存在していることが多く、依存関係を設定していないと適用する前にエラーになってくれたりするので迷うことが少なくなります。

また、サンプルで組み合わせた書き方が充実していたり、組み合わせサンプルのコードが用意されていたりするので、手順を読んで試行錯誤するより確実にインフラ構築をすることができます。

特に AWS で CDK や Copilot といったツールを使っておくと、複雑なサービス間の依存関係を考えることがなく構成を立ち上げることができます。

設定できるパラメーターがツールのドキュメントに網羅されている

依存関係と同様に、全てのパラメーターがドキュメントに書かれているので、「このリソースではこれが設定できる」とか「このリソースはこの設定をすることができない」というのがドキュメントを読むだけで把握することができます。

ただし GCP の Cloud Run のようなメタデータでパラメーターを指定するような類のものの場合や、AWS RDS のパラメーターグループのような任意のものを指定するようなものはドキュメントには書かれていないので、そこはオフィシャルのドキュメントやコンソールの画面を併せて読む必要があります。

まとめ

コンソールで試行錯誤するより、最初からコードで書いて試行錯誤したほうが良いことが多いです。手作業を後からコード化するのは二度手間にもなるので、学習目的とかでない限りは最初からコードを書きましょう。

もちろんある程度の IaC ツールに慣れておく必要や、クラウドインフラの使い方に慣れておく必要がありますので、そこは基礎教養として素振りしておきましょう。

Webエンジニアが新規でプロジェクトに入った時に確認すること

フリーランスとしてWebエンジニアをしておりますが、プロジェクトに新規に入った時にどういう点を確認しているのかをまとめておきたいと思います。

プロジェクトの目標と直近の目標が問題ないか

プロジェクトの最終目標(理想)はとにかく大きくあるべきで、一方で直近の目標は具体的かつ十分に実現可能なサイズになっているべきです。もちろんその間くらいの目標(いわゆるマイルストーン)も存在しているはずです。

フリーランスの立場だと目標そのものに直接口を出すことはないですが、直近の目標が大きすぎると手を動かす時に困ってしまいますので、どこを削ぎ落とすのが良いのかこちらから提案することはあります。

開発プロセスが問題ないか

プロジェクト参加直後はベロシティ(スプリント期間内の平均作業量)が不安定ですので、そこを許容できてちゃんと

個人的には常にスクラムである必要はないと思いますが、マネージャーがいる場合はマネージャーが各メンバーのベロシティをちゃんと把握している、不在の場合は自分でベロシティが把握できていてタスクの見積もりができる、という状況になっていれば良いかと思います。「何だかよくわからないタスクをよくわからない期間で対応している」という状況では、前述の直近の目標の提案と同時に対処方法の提案を行うこともあります。

デプロイが安定かつ高速に行えているか

デプロイ速度は修正速度に直接繋がりますし、安定したデプロイができなければデプロイする単位が大きくなりがちですので、デプロイの安定性は最重要になります。

当然デプロイは完全自動化されていて、誰でも気軽に(承認フローなどは別として)デプロイできることが前提です。

誰でも簡単にデプロイできない場合、誰かにデプロイをお願いするというようなことが発生します。これでは自分と誰かの作業と、それを連絡する作業が増えてしまい、当然作業効率が悪くなってしまいますので、「誰でも」は重要です。「コマンド一発でデプロイできる」と見えても「(コマンドを実行する前にアクセスキーを取得して手元でデプロイ準備をして…)コマンド一発でデプロイできる」という場合がよくありますので、デプロイ環境自体が CI/CD 環境に移されていて手元の環境に影響せずデプロイできる( CI サーバーが落ちていた場合は手元でも実行できる)というのが理想です。

デプロイ方法が複雑になっていないか

安定して高速にデプロイできていても、それを処理している方法が複雑だとメンテナンスの時に困ります。

メインのコードは綺麗にできてもインフラ系のスクリプトは長くなりがちみたいなケースはよく見かけますが、インフラ系のスクリプトもメインのコード同様に読みやすく構造化されているべきです。またインフラ系はツールが充実していることが多いので、なるべく自分で書くスクリプトは最小限にするのが良いと思います。

デプロイ自体が安定高速動作していればとりあえずは問題ないので、ここは後回しにすることも多いです。

CI でコード品質が十分に守られているか

CI の整備は後になればなるほど大変です。1これは CI で行うことの多くはコード品質そのものを一定の品質にする( lint など)もののため、コード量が増えた後からそれを適用しようとすると修正点が膨大になるためです。 lint はとにかくコード量が増える前に対処することが大事なので、ここは真っ先にチェックを行います。リリース前プロジェクトであればすぐ導入しますが、リリース後だと手を入れにくいので、最小限の設定にして少しずつ厳しくするという手法を採ります。

(自動)テストはそもそもテストが書けているかというのをまず確認しますが、その上で「テストに再現性があるか」「テストの内容が十分か」「Test Sizes の分類が十分にできているか」といった内容を確認します。

数回に1回落ちるようなテストがある場合で、それがテストの実行順に影響している場合はテストの書き方そのものに問題がある場合がほとんどですので、その場合は削除してしまったほうが良いことが多いです。一方で、時間に関わるテストや、乱数や数値計算の誤差などが影響するようなテストは、それ自体が重要なケースが多いのでちゃんと調査したほうがいいと思います。

Test Sizes は、テストの分類を「単体テスト」「結合テスト」といった曖昧な呼び方ではなく、「我々のプロジェクトでは3段階の分類があり、それぞれのレベルではこうなっている」というものをプロジェクト固有で定義しようというものです。

ローカルでの環境構築が問題なく行えるか

自分が受け入れられる側になるのですが、この時に受け入れ準備が十分にできているか確認し、できていない場合は改善しながら作業することになります。

一番ありがちなのは環境構築手順が整備されていないということで、これは自分がそのまま作業するのですぐわかります。

ローカルの開発に外部のサーバーが必要な場合はまずそれがローカルで再現できないのか確認します。単なる MySQLPostgreSQL などをサーバーに繋いでいる場合はローカルで立ち上げるように変更します。エミュレーターが用意されているサービスであればそちらを使うようにします。この際に設定が直接書かれていたり ENV などでの切り替えしか対応していない場合は、設定を環境変数に出して変更可能にします。2 最近だと自分は M1 (Apple Silicon) Mac を使用しているので、この環境で動作しないものを使っているという場面に遭遇することもあります。この場合は Docker 化を真っ先に行います。

手順はあるけど手順通りにやっても上手く行かないという場合、「使っているライブラリのアップデートで動かなくなった」というケースと「プログラムの構造の変化に対応していない」というケースが多いです。どちらにしても変更を把握できていないということが原因ですので、メンテナンス体制に難があることが多いです。外部ライブラリの更新などは把握しておく、自分で修正した場合は環境構築手順もアップデートするフローにしておく、ということが必要になります。

受け入れタスクが十分に実施可能な内容になっているか

ここでの障害は「ライブラリやツールの使い方が独自性の強いものになっていないか」「暗黙の知識が多用されていないか」といったものがあります。もちろん前述までの内容がクリアになっていないと作業に入ることもできませんので、それらを取り除いた後にようやく作業ができるということになります。

「ライブラリやツールの使い方が独自性の強いものになっていないか」というのは、自作ライブラリとかを使っている場合は当然ですが、ベストプラクティスに即していないようなライブラリの使い方をしているとか、魔改造されているというような場合には、なるべく本来の使い方に戻すよう指摘することがあります。「ライブラリやツールの公式のチュートリアルを見た上でそれを使っている部分を読んだ時にすぐ理解できるようになっているか」というのが指標になります。

「暗黙の知識が多用されていないか」はそのままですが、プロジェクト固有の暗黙の知識がある場合は当然手を入れることができません。暗黙の知識が登場する場合はコメントなどで把握できるようになっていること、仕様と実態の乖離がないことなどを確認します。

まとめ

これらの点がクリアされているプロジェクトであれば、新しく人を入れることも容易ですし、引き継ぎの時にも困らないのではないかと思います。

書き漏れがあるかもしれないので、思い出したら追記する可能性があります。

今回はインフラの話は除外しましたが、インフラでチェックする点もまた機会があればまとめてみたいと思います。

これらの点でお悩みの方は是非私までご相談をお願いします。詳細は https://nazo.dev/profile をご覧下さい。

M1(Apple Silicon) Mac に google-cloud-sdk を無理やりインストールする(2021/01/19時点)

公式からダウンロードしてきた tarball からインストールすると以下のエラーが出ます。

/google-cloud-sdk ❯❯❯ ./install.sh
Welcome to the Google Cloud SDK!
Traceback (most recent call last):
  File "/Users/nazo/google-cloud-sdk/bin/bootstrapping/install.py", line 12, in <module>
    import bootstrapping
  File "/Users/nazo/google-cloud-sdk/bin/bootstrapping/bootstrapping.py", line 32, in <module>
    import setup  # pylint:disable=g-import-not-at-top
  File "/Users/nazo/google-cloud-sdk/bin/bootstrapping/setup.py", line 57, in <module>
    from googlecloudsdk.core.util import platforms
  File "/Users/nazo/google-cloud-sdk/lib/googlecloudsdk/__init__.py", line 23, in <module>
    from googlecloudsdk.core.util import importing
  File "/Users/nazo/google-cloud-sdk/lib/googlecloudsdk/core/util/importing.py", line 23, in <module>
    import imp
  File "/opt/homebrew/Cellar/python@3.9/3.9.1_6/Frameworks/Python.framework/Versions/3.9/lib/python3.9/imp.py", line 23, in <module>
    from importlib import util
  File "/opt/homebrew/Cellar/python@3.9/3.9.1_6/Frameworks/Python.framework/Versions/3.9/lib/python3.9/importlib/util.py", line 2, in <module>
    from . import abc
  File "/opt/homebrew/Cellar/python@3.9/3.9.1_6/Frameworks/Python.framework/Versions/3.9/lib/python3.9/importlib/abc.py", line 17, in <module>
    from typing import Protocol, runtime_checkable
  File "/opt/homebrew/Cellar/python@3.9/3.9.1_6/Frameworks/Python.framework/Versions/3.9/lib/python3.9/typing.py", line 26, in <module>
    import re as stdlib_re  # Avoid confusion with the re we export.
  File "/opt/homebrew/Cellar/python@3.9/3.9.1_6/Frameworks/Python.framework/Versions/3.9/lib/python3.9/re.py", line 124, in <module>
    import enum
  File "/Users/nazo/google-cloud-sdk/lib/third_party/enum/__init__.py", line 26, in <module>
    spec = importlib.util.find_spec('enum')
AttributeError: module 'importlib' has no attribute 'util'

curl でインストールするともう少し進みますが以下のエラーが出ます。

~ ❯❯❯ curl https://sdk.cloud.google.com | bash
(略)
Welcome to the Google Cloud SDK!

To help improve the quality of this product, we collect anonymized usage data
and anonymized stacktraces when crashes are encountered; additional information
is available at <https://cloud.google.com/sdk/usage-statistics>. This data is
handled in accordance with our privacy policy
<https://cloud.google.com/terms/cloud-privacy-notice>. You may choose to opt in this
collection now (by choosing 'Y' at the below prompt), or at any time in the
future by running the following command:

    gcloud config set disable_usage_reporting false

Do you want to help improve the Google Cloud SDK (y/N)?


This will install all the core command line tools necessary for working with
the Google Cloud Platform.

Beginning update. This process may take several minutes.
ERROR: (gcloud.components.update) The following components are unknown [anthoscli, kuberun].

これは anthoscli kuberunコンポーネントがインストールできない( gcloud components install anthoscli kuberun と同等)のが原因です。

回避するには、curl で上記エラーが出た時点で ~/google-cloud-sdk にファイル一式があるはずなので、移動して以下のように実行します。

~/google-cloud-sdk ❯❯❯ ./install.sh --override-components core gcloud-deps bq gcloud gsutil
Welcome to the Google Cloud SDK!

(略)

Your current Cloud SDK version is: 323.0.0
Installing components from version: 323.0.0

┌────────────────────────────────────────────────────────────────────────────┐
│                    These components will be installed.                     │
├─────────────────────────────────────────────────────┬────────────┬─────────┤
│                         Name                        │  Version   │   Size  │
├─────────────────────────────────────────────────────┼────────────┼─────────┤
│ BigQuery Command Line Tool                          │     2.0.64< 1 MiB │
│ BigQuery Command Line Tool (Platform Specific)2.0.58< 1 MiB │
│ Cloud SDK Core Libraries (Platform Specific)2020.07.10< 1 MiB │
│ Cloud Storage Command Line Tool                     │       4.573.5 MiB │
│ Cloud Storage Command Line Tool (Platform Specific)4.51< 1 MiB │
└─────────────────────────────────────────────────────┴────────────┴─────────┘

For the latest full release notes, please visit:
  https://cloud.google.com/sdk/release_notes

(略)

For more information on how to get started, please visit:
  https://cloud.google.com/sdk/docs/quickstarts

インストールに成功しました。

override-components で指定した引数は、以下で確認したものからエラーが出るものを抜いたものになります。

~/google-cloud-sdk ❯❯❯ cat bin/bootstrapping/.default_components
["core", "gcloud-deps", "bq", "gcloud", "gsutil", "anthoscli", "kuberun"]%

anthoscli も kuberun も、おそらく無くて困る人は多くないのではないかと思いますので、抜いてインストールしてしまっていいと思います。

2020年の仕事と技術の振り返り

今年は合計2社にお世話になりました。ところでフリーランスで関わった会社名とか公表するものなのでしょうか?

関わり方

1社最大週2で、なるべく事業ドメインから遠いところをお手伝いする、というスタンスで働きました。事業ドメインに直接関わるものだと大抵はスピード感(主に緊急対応という意味で)が必要になるため、なるべくそこから遠いけど役に立つ内容で関われるものでお手伝いしております。

1社週2にしているのは、複数社の案件を同時に受けたいというのがありましたが、実際には私の知名度が足りなくそこまで仕事が回ってくることはありませんでした。数ヶ月だけ週2 x 2社の状態はありました。週5は疲れてしまうので当面はしない予定です。

原則として準委任契約による月額払いでの契約をお願いしております。これは私は一人でアプリを全部仕上げたりデザインを納品するような作業は得意としておらず、テクニカルな困りごとを臨機応変に対応するという内容を中心に活動しているためです。また原則フルリモートでお願いしております。

Rails によるアプリケーション開発 1社目

Rails のバージョンを 4 -> 5 に上げる仕事、同時に Webpacker のバージョンも同様に上げる仕事を中心に行いました。

Rails 側は元の書き方がそこそこ行儀が良い( Rails そのものを魔改造していない)ために問題になることは少なかったですが、Webpacker 側は動かないものが大量発生して大変でした。アップグレード作業は定形で引っかかる箇所もありますが、どちらかというと固有の事情を解決することが多そうなので、どれだけ全体を把握できるかが勝負になると思います。

Elixir ( Phoenix ) + Vue ( Nuxt ) + AWS EKS によるアプリケーション開発

Elixir 全く書いたことなかったのに誘っていただいて貴重な経験ができました。今年はほぼこの案件を中心に動いていました。実稼働している k8s を触れたのも良い経験になりました。

Elixir はパターンマッチが強力なため、今までとはちょっと考え方を変えて書かないといけないところもあり、頭の体操的な面白さがありました。一方で Erlang/OTP 側がわからないと詰まるところもたまにあり、そのあたりの調査力はまだまだ不足していると感じました。あとドキュメントが少ないので大体ソースコードを直接追うことが多いのも大変かなと思います。利用者がもっと増えてほしいところです。

アプリケーション側以外で大きくやったこととしては、以下のようなものがあります。

  • 既存インフラの Terraform 化(Terraform Cloud)
  • ExUnit でのテスト整備
  • Lamnda@Edge での OIDC 認証
  • Headless CMS の採用

特に Terraform 化では、既存のインフラとの整合性を保ちつつ IaC しやすい構造を作るというところで多少矛盾が生じるところもあり、落とし所を見つけるのが大変でした。「ここはインポートしたけど新しく追加しないで!」というような感じのコメントを残したりすることでなるべく今後も秩序を維持できるように残しておきました。

前職でアーキテクチャ設計やCI/CD設計などを全て自分がやるしかなかった経験が生かされ、ある程度構成を見ただけで実用的なTerraform分割の道筋がすぐ見えるようになったと思います。またCI/CDワークフローも整備し、誰でも安全にデプロイできるようにしておきました。

その他プライベートでやったようなこと

ECSのタスクスケジューラをどうにかしたかった

AWS ECSのバッチ処理をもう少し使いやすくできないかなーと試行錯誤し、Goでシンプルなスケジューラーでも書こうと思ったのですが、すぐにやる気が消えてしまったのでやめました。ECSの異常終了の検知が思ったより簡単だったのでそれでいいかなという感じもします。( AWS ECSのタスクが異常終了したらログURL付きでSlackに通知する - nazolabo

現在は MWAA( Amazon Managed Workflows for Apache Airflow (MWAA) のご紹介 | Amazon Web Services ブログ )も存在し、Airflow側でもawslogsから実行結果を取得する機能が入っていますので(Airflowのタスク実行環境を分離する|Dentsu Digital Tech Blog|note)、ECSのタスクスケジューリングでは機能不足な場合でも困ることはないのではないかと思います。

Vue 3.0 (というか composition API

使うかどうかわからないのですが、Vue/Nuxtの最新を追うためにいくつかコードを書いていました。 https://github.com/nazo/binsen/pull/7

現在のVue/NuxtはReact/Nextの後追いになっている感じが強く、もともとNuxtのほうが実用性としては先行していたはずだったのにというところから、もっとReactとは違う良さを出していってほしいなという感じがします。とはいえ現時点でのフロントエンドはNextかNuxt以外は選択肢にはないと思います。

WebAssembly

nazo.hatenablog.com

感想と今後

週2で開発業務は翌週に記憶が切れていることが多く、単純にもう1日やったほうがいいなと思うこと多かったので、事業ドメインから外れていてもなかなか厳しいと思いました。よほどピンポイントに専門的な内容を行う場合(技術顧問的な?)でない限り、週3はあったほうがいいのではないかと思います。

声をかけていただいた会社さんの中には良いポジションを提示してくれたところもあったのですが、週5・出勤あり・正社員でと言われるとお断りするしかないため、申し訳なく思うところもありました。とはいえ今の働き方が現時点では一番良いと思っているので、当面このままで続けていこうと思います。(将来的には変えるとは思います)

こちらから積極的に声をかけていないということもあり、残念ながら現在仕事が途切れてしまっている状態なので、現在積極的に仕事を募集しております。気軽にご連絡をお待ちしております。詳しくは ポートフォリオ · GitHub をご覧下さい。

それでは来年も皆様宜しくお願い致します。

rust-nesをwasm化した

github.com

相変わらずOAM描画もキー入力も実装されていないのにNESエミュレーターってレベルじゃないだろという感じですが、ついでに元のrust-nesよりいくつか修正してwasmで動くようにしました。ちなみに元のバージョンはSDLです。

GitHub - rustwasm/wasm-pack: 📦✨ your favorite rust -> wasm workflow tool! を使うと、手軽にRustでWebアプリケーションを書くことができます。コアになるライブラリは GitHub - rustwasm/wasm-bindgen: Facilitating high-level interactions between Wasm modules and JavaScript なのですが、wasm-packはこれにWebpackなどを追加し、ホットリロード的なものとかを最初から提供してくれるものです。

Examples - The `wasm-bindgen` Guide が充実しており、今回必要だったcanvasやfetch、requestAnimationFrameなどはもちろん、WebGLやWebRTCのサンプルもあり、すぐに試すことが可能です。Rustが書ける方であればすぐに使えると思います。

WebAssemblyの現実的な用途としてはWeb的なものよりバイナリ操作的なものが中心になるのではないかと思うのですが、突然使うことになるかもしれないので今のうちに触っておいて損はしないのかなと思っています。

久々に触ってて面白かったので、もう少し機能を実装したいところです。

nuxt/http で axios-module の credentials: true を再現する

https://github.com/nuxt/http は実質 https://github.com/nuxt-community/axios-module の後継に当たるもので、fetch APIをベースにした https://github.com/sindresorhus/ky を利用しています。

qiita.com

Migration Guides - Http Module を見てわかる通り、axios-module と比較しても名前が変わっただけのような作りになっており、置換だけでほぼ完全に移行することができますが、nuxt/http では credentials: true オプションが削除されています。今回はこれをどうしたらいいのかという話になります。

そもそも axios-module の credentials: true とは?

axios-module の credentials: true は、 XMLHttpRequest に対し withCredentials = true をデフォルトで設定するためのオプションです。クロスドメインCookie等の資格情報をXHR経由で渡す時に設定するものです。

yamory.io

withCredentials オプションは XHR 固有のもののため、fetch API には存在しません。代わりに credentials = 'omit' | 'same-origin' | 'include' というオプションが存在します。

  • omit : 同一ドメイン上でも資格情報が送られない
  • same-origin : 同一ドメイン上でのみ資格情報が送られる
  • include : 全てのドメインで資格情報が送られる

XHR での withCredentials = false が 'same-origin' で、 withCredentials = true が 'include' に該当します。(ただし polyfill を使うと omit に該当する XHR のオプションが存在しないために同一ドメイン上では資格情報の送信が行われます) なおサーバー側の Access-Control-Allow-Credentials 等は状況に応じて別途必要です。

nuxt/http で再現する

該当のオプションが存在しない nuxt/http で再現するには、デフォルト値を無理やり書き換える必要があります。プラグインで対応します。参考:Globally set options.Credentials · Issue #92 · nuxt/http · GitHub

export default ( { $http } ) => {
    $http._defaults.credentials = 'include'; 
}

TypeScriptではプロパティにアクセスができないので、型を破壊して強引にプロパティを変更します。

import { defineNuxtPlugin } from '@nuxtjs/composition-api';
import { Context } from '@nuxt/types/app';

export default defineNuxtPlugin(({ $http }: Context) => {
  ($http as any)._defaults.credentials = 'include';
});

まとめ

セキュリティ上の懸念点があるためにこのような対応が行われていると思いますので、強引に変えるのは良くないのではないかと思います。

nuxt/http では setToken() というメソッドが用意されており、 Authorization ヘッダをこちらでグローバルに指定することが可能です。こちらで資格情報を管理するのが良いのではないかと思いますが、axios-module と互換性があると言うのであれば credentials 指定があっても良かったのではないかと思います。