特急はまかぜ大阪行きは姫路駅で長時間停車を行うことがありますが、播但線ホームに停車するため停車したホームには売店がありません。しかし隣のホームには売店が見えます。
何とかして買いたいですが、播但線から出るには中間改札を抜ける必要があります。しかし中間改札を抜けると切符を取られて戻ってこられなくなりそうです。中間改札を出入りして売店を利用することはできないのかと思ったのですが、流石に事故ると怖いし、実験するのも大変なのでJR西日本に聞いてみました。
結論としては停車中に中間改札を往来することは可能ですが、ICカードで自動改札を利用するとエラーになるので駅係員に切符ないしICカードを提示して通行すれば問題ないとのことでした。
勿論、改札通過時に駅員が別に対応をしているなどではまかぜの乗車に間に合わなかった場合は自己責任になるので、ほぼ賭けです。ぶっちゃけほとんどやる意味はないと思います。ただ香澄駅からはまかぜ6号に乗ると駅弁がないんですね。折角の特急なので食べたいじゃないですか。そもそもあの時間に駅弁売ってるかや、在来線ホームでいまだに販売があるのかが謎ですが…ｗ
タイトル通りトップページのレイアウトを変えてみました。
誰が見に来てるのか解らない部分なので変えたところでアレですが…ｗ（トップページはアクセス計測してないので。。。）
変更前は縦長のレイアウトだったのですが、もうちょっと余白を活かした方がいいかなと思い、横にもレイアウトしてみました。デザインセンスが皆無なのでなんか余計に微妙になった気もしますが…。
他にも表組だった場所を段落にしたり、Sponsoredのバナーを縦置きにしたり細々と変えてます。
| 変更前 | 変更後 |
|---|---|
 |
 |
経験技術のところは見やすさがマシになったと思います。余白が詰まって少し息苦しくなった気もします。
PCビューが縦長だったのはレスポンシブ対応をサボる為というのもあったので、今回はそこそこ真面目にやりました。結果、まぁまぁちゃんとレスポンシブになっているとは思います。まぁ、一応本業なので…。ブレークポイント周りの挙動は怪しい気もしてますが…（
| 変更前 | 変更後 |
|---|---|
 |
 |
半ば何のためにあるかわからないトップページですが、素のHTMLを書く機会が少ないので、それを書くためだけにある節があります。それもあってJSは入れず、HTMLとCSSだけで書いてます。
一応自分なりにセマンティクスには拘って書いているつもりですが、概ね自己満足レベルな気はしています。Lighthouseの数値は悪くない気がするので、無難なところかなという気はしていますが…。
Lighthouseの結果は取り合えずぼちぼちな気はする。
まぁまた気が向いたときにいじろうと思います。この新レイアウトも8月頭に着想して原型を作って、中途半端な状態で今日まで放置してたのを直して何とか形にしたくらいなので…。
こんなんでもやってるとMedia Queries Level 4という新機能を知れたり、HTMLやCSSを書く能力が多少は鍛えられるので悪くないです。
MDNによるとMedia Queries Level 4の対応状況は「それなり」ということですが、今回使用したMedia Queries: Range Syntaxは、どのブラウザも対応してくれてそうで良かったです。MDNでも全てのブラウザがFull supportとあるので安心です。
ローカルで動作するNode.jsのライブラリ（node_modules）欲しくないですか？欲しいですよね？という訳で作ってみました。
要件としてはTypeScriptで実装出来、Jestでテスト可能で、ESLintでLintが可能というところです。
| Env | Ver |
|---|---|
| @swc/cli | 0.1.62 |
| @swc/core | 1.3.93 |
| @swc/jest | 0.2.29 |
| @types/jest | 29.5.5 |
| @types/node | 20.8.6 |
| @typescript-eslint/eslint-plugin | 6.7.5 |
| @typescript-eslint/parser | 6.7.5 |
| eslint | 8.51.0 |
| eslint-config-prettier | 9.0.0 |
| eslint-plugin-jest | 27.4.2 |
| jest | 29.7.0 |
| jest-watch-typeahead | 2.2.2 |
| prettier | 3.0.3 |
| ts-jest | 29.1.1 |
| typescript | 5.2.2 |
| Node.js | 20.8.0 |
| npm | 10.1.0 |
monorepoでmainからlibrary/singleやlibrary/multi/hoge, piyoを参照するような構成です。
root
└─packages
├─library // ライブラリ側
│ └─packages
│ ├─multi // 複数ファイルのライブラリ
│ │ └─src
│ │ └─utils
│ │ ├─hoge
│ │ └─piyo
│ └─single // 単一ファイルのライブラリ
│ └─src
└─main // ライブラリを使う側
└─src
└─libs
これが全てというわけではないと思いますが、一旦今回作ったもののポイントを解説していきます。利用側がtscを利用しない場合、ライブラリ側と利用側で構成は別々になります。
またこの実装はエディタにVSCodeを利用し、importするパスが相対パスであることを前提に説明しています。
まずビルドに関してはtscでやります。
これはTypeScriptで開発するためにはビルド成果物として.d.tsファイルが必要になるのと、Jestを通すためにビルド成果物がCommonJS形式（以下CJS）である必要があるためです。CJSが吐けるなら何でもいいとは思いますが、.d.tsも必要になるので、tscを使うのが無難な選択肢だと思います。
テストファイルを出力したくないので、tsconfig.jsonはビルドと開発で分けます。
またtsconfig.jsonは各ワークスペースのルートに置いて置く必要があります。これはTypeScriptがtsconfig.jsonのパスを起点として動作するためです。
ビルド用の設定ポイントとしては以下の通りです。
"compilerOptions"
"module": "NodeNext"
"moduleResolution": "NodeNext"
"declaration": true,
.d.tsの出力に使います"outDir": "./dist",
"exclude": ["src/**/*.spec.ts"]
"include": ["src/**/*"]
ビルドにtscを使うため、Jestのローダーとしてもts-jestを利用します。公式ではbabelが推奨されているようですが、構成方法が不明だったので諦めました。BabelはJest公式の案内通りにやっても多分上手く行きません。
jest.config.jsには以下の設定を追加します。
preset: 'ts-jest'
開発とビルドでtsconfig.jsonを分けるので、開発用のも必要です。これはビルド用から"exclude": ["src/**/*.spec.ts"]を抜くだけです。
ライブラリを外部参照させる方法
基本的にはpackage.jsonに外部参照させるための定義を書くことによって行います。
この辺りの仕様はdocs.npmjs.comにはなく、nodejs.orgにあります。
単一ファイルの外部参照
単一ファイルを外部参照（import出来るように）するときに使う手法です。
importをimport { hoge } from '@my-lib/example'みたいな書き方をしたい時に必要になるやつです。
以下の様にビルド成果物の.jsのパスをpackage.jsonに追加してやると出来るようになります。
"main": "./dist/index.js",
以下の書き方でも同様に可能です。
"exports": {
".": {
"default": "./dist/index.js"
}
},
上記には他にtypesというフィールドがあり、本来ここに.d.tsを追加するのですが、TypeScriptが解決してくれるので、なくても動きます。一応ない場合はファイル探索を行うようなので、あった方が少しだけパフォーマンスが上がるかもしれません。
複数ファイルの外部参照
複数ファイルを外部参照（import出来るように）するときに使う手法です。
基本的に何もしなくてよいですが、import { hoge } from '@my-lib/example'みたいな書き方もしたい場合は以下の記述が必要です。
"main": "./dist/core/index.js"
ここで指定していないものはimport { hoge } from '@my-lic/example/dist/hoge'みたいにして参照します。distがダサくて嫌な場合は適当な名前に変えます。
参考までに@actions/githubはバージョン6.0.0時点でdistに相当する部分をlibにしており、import { Context } from '@actions/github/lib/context';の様にして参照するようになっています。
exportsを使ってdistを隠すことも出来るとは思うのですが面倒なので試してません。
今回利用する側はビルドにswcを使う想定ですが、たぶんなんでも動くと思います。参考までにswc-loader + webpackでも動きました。
tsconfig.jsonに以下の設定があれば恐らく最低限大丈夫だと思います。
"compilerOptions"
"module": "NodeNext"
"moduleResolution": "NodeNext"
"include": ["src/**/*"]
以下のように相対パスを指定するとインストールできます。
npm i ../package/library/package/single
消すときはパッケージ名を指定すれば消せます。
npm un @lycolia/library-example-single
色々してる過程で試行錯誤した名残。
以下の二通りの設定は試しましたが、どっちもダメだったので諦めました。何よりtscを使うならts-jestの方が楽なのは確定的に明らかですし…。
presets: [
['@babel/preset-env', {targets: {node: 'current'}}],
'@babel/preset-typescript',
],
presets: [
['@babel/preset-env', {targets: {node: 'current'}, modules: 'commonjs'}],
'@babel/preset-typescript',
],
.swcrcを以下の設定にしても
"module": {
"type": "commonjs"
},
以下の出力がされるため、jest.spyOn()が上手く動かない（getが邪魔でhelloが見れない
"use strict";
Object.defineProperty(exports, "__esModule", {
value: true
});
Object.defineProperty(exports, "hello", {
enumerable: true,
get: function() {
return hello;
}
});
const hello = (param)=>{
console.log(param);
};
どの道これでは.d.tsが出せないので、あんま意味ないなと…。
実装方法は@actions/githubが一番単純で参考になると思います。
実装はビルド成果物とビルド前のコード、package.jsonやtsconfig.json辺りがどうなっているのかを参考にしました。
ESM化が叫ばれて久しいですが、未だにJestはESMとCJSが混在したコードを処理してくれません。
Getting StartedにもSWCに対する言及がないので、きっともう忘れられているのでしょう。swc-project/jestの方も特にやる気はなさそうだし、やりたければ自分でPR書きましょうって感じだと思います。きっと。
node_modules配下にESMで作られたモジュールが存在し、コードはTypeScript、トランスパイルにはSWCを利用する。
| Env | Ver |
|---|---|
| @swc/cli | 0.1.62 |
| @swc/core | 1.3.92 |
| @swc/jest | 0.2.29 |
| @swc/register | 0.1.10 |
| jest | 29.7.0 |
| typescript | 5.2.2 |
package.jsonのtypeをmoduleにするjest.config.jsのtransformIgnorePatternsにESMモジュールのパスだけ除外する設定を書くtransform.jsc.pathにpkg-name: ['node_modules/pkg-name']を追記するnode --experimental-vm-modules node_modules/jest/bin/jest.jsで実行する
多分Webpackでバンドルしてnode_modulesの中身も外も関係ない状態にするのが一番無難なのではないかと思いました。
Node.jsの組み込みテストランナーにすれば解決するかな？と思ったものの、こちらは現状SWCでは使えそうにないので諦めました。
参考までに以下のコマンドで走らさせられます。
node --require @swc/register --test ./src/**/*.spec.ts
取り敢えずESMに引っかったモジュールはCJS時のバージョンを維持しておくことにしましたが、このままだとSWC使えないし、なんとかなって欲しいですね。Webpack使えば解決できるのはわかるんですが、このために使いたくないので、テストを重視する場合、Vitestを持つViteが有力候補になって来そうです。
esbuild + Node.js built-in test runnerの組み合わせであればテストはできるが肝心の実行ができず無意味だった
新しくセットアップしたTypeScriptのプロジェクトでauto-importが機能しなかったので原因を調べた。
ここ数年ちまちま起きて、そろそろイラついて我慢の限界を覚えたので…。
| Env | Ver |
|---|---|
| VSCode | 1.83.0 |
| typescript | 4.8.4 |
再現用のサンプルリポジトリでsrc/index.tsの下図コードに対してauto-importが発動する操作を行う。
恐らく以下を全て満たすときにauto-import操作をしようとした時に発生する。地味にややこしい。
node_modules配下に存在し、@types/モジュールを持たないものでかつ、同一プロジェクト内でimportされておらず、package.jsonのdependenciesに書かれていない。
因みにhoge/piyo/fugaのようなモジュールはhogeだけがdependenciesにいてもauto-importが動かない。これを全部package.jsonのdependenciesに書いていくのは目眩がするので正直auto-importを諦めて自分でimportを調べて書くのが無難だと思う。
TypeScript 4.0で実装されたSmarter Auto-Importsのせい。
node_modulesをクロールすると重すぎるので@types/だけ読み込んで、あとはpackage.jsonのdependenciesも見るようにしたよという内容らしい。
package.jsonのdependenciesに全部のモジュールを書いていくというのが解決方法になるが、気が遠くなるので諦めた方がいい。初回だけは苦痛でもimportパスをどうにかして調べて手動で書いて、あとはauto-importされるのを期待するのが良いだろう（そんな何度もimportしないと思うが…）
取り敢えず基本npm iで入れて行き、スラッシュ区切りのやつは諦めるくらいがちょうどいいだろう。
再現用のサンプルリポジトリではpackage.jsonのdependenciesに"firebase/app": "^10.4.0"を追加することでsrc/index.tsのinitializeAppに対しauto-importが発動する様になるはずだ。
早い話、node_modules配下にあって@types/を持たないものはTypeScriptに対応する気がないんだな程度に思っておくのが良いだろうが、TS化で@types/を廃止したライブラリがある当たり、すごく微妙な感じがある。ちょっとなんとかしてほしい。
そもそもpackage.jsonのdependenciesはnpm packageを公開する時に動作するために必要な依存関係を登録する場所で、型の補助をする場所ではなかったはずだ。
少なくともnpmjsのdevDependenciesには以下の記述がある。つまりモジュールを配布する時に動作に不要な依存関係を含まないようにするためにdevDependenciesがあるということだ。つまりdependenciesには動作に必要なものだけを入れるべきで、モジュールを配布しない場合、このフィールドは不要になるはずである。
If someone is planning on downloading and using your module in their program, then they probably don't want or need to download and build the external test or documentation framework that you use.
In this case, it's best to map these additional items in a devDependencies object.
ただTypeScriptがdependenciesに書かないとauto-importが失敗すると言っているので使うものはdependenciesに入れるというのが良いのだろう。（配布しないモジュールだとしても）
ただそれにしてもauto-importを動かすためだけに、dependenciesに同一モジュールのスラッシュ違いを大量に入れていくのはバカバカしいと思う。
"dependencies": {
"firebase": "^10.4.0",
"firebase/app": "^10.4.0",
"firebase/database": "^10.4.0",
"firebase/analytics": "^10.4.0",
...
}
かといってinitializeAppがfirebase/appにあるなんて知らんわけで、全部のパスに総当りしていくのも嫌だし、一々リファレンス漁るのも面倒だし、なんかもうちょっといい具合になって欲しい…。