4
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

npm pack/publishでファイルの更新日時が1985-10-26固定になっていた

Last updated at Posted at 2019-05-09

概要

作成したパッケージの中身が微妙な更新日時になった。何か壊れたのかと思ったが、1985-10-26 (日本では17:15)になっているのは意図された動作だった。
一年経った話だが検索しやすさに貢献して微妙に役に立つのではないかと思って書いた。環境は Windows 10 10.0.17763.475、node 10.15.3、npm 6.4.1。

経緯

npmにパッケージを公開する際、npm publish の前に npm pack で tgz ファイルを作成して下記のことを確認していた。

  • 余計なものが含まれていないか
  • 公開用のファイルが古くないか

いちいち見るのは疑問があるけど、やっていると追加したテストやドキュメント等を同梱してしまったり、READMEが参照する画像がなかったりが発生するし、ミスして面倒くさくなるよりはいいのでそうした。

2019-05-09、作業してみるとファイルの更新日時が「1985-10-26 17:15」になっていて、従来のようにファイル更新日時確認ができない。
しかも「1970-01-01」ではないので何か壊れたのかと思った。

情報を探すと一年前のイシューが見つかった。

2018-05-06 npm 5.7.1 pack/publish setting timestamp to epoch · Issue #19968 · npm/npm

ハッシュ値がファイル日時だけで変わらないように「1970-01-01」にセットしたら問題があったので、都合悪くなくなるまでずらしたらしい(それでもトラブル発生した人がいるけど)。最近 npm を更新するまで気付かなかった。

これを書きながら「npm 5.7.1 pack/publish」で検索したらQiitaのエントリが見つかる。コメントまで読めば意図的な変更であることもわかる。

npm@5.7.[01]npm packnpm publish して作成されるtgzのタイムスタンプがおかしいのでご注意ください - Qiita

さほど言及がないようで、目立ってメジャーな問題ではなかったのかな、と思った。

結末

不具合ではなく意図的な動作なので、あとはこちらの問題しかない。
結局「提出されるパッケージが持つファイルの確認」はコマンド実行時のファイル一覧表示で済むし、
ファイルの日時は scriptsprepublishOnly でスクリプト実行させてチェックすればいい、というより別にやらなくていい(かつては気を付ける必要があった)ということになり、結果的に良くなった気がする。

4
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
4
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?