Vue cli 3 はよいという話を以前書いたんだけど、Jest でテストできるようになるまで一つだけすごくハマったものがあって、それは Babel runtime の除外設定。

ちなみにバージョンは以下の通り。

@babel/core 7.3.3
jest 24.1.0

エラーはこういうもので、

Jest encountered an unexpected token
This usually means that you are trying to import a file which Jest cannot parse, e.g. it's not plain JavaScript.
By default, if Jest sees a Babel config, it will use that to transform your files, ignoring "node_modules".
Here's what you can do:
To have some of your "node_modules" files transformed, you can specify a custom "transformIgnorePatters" in your config.
If you need a custom transformation specify a "transform" option in your config.
If you simply want to mock your non-JS modules (e.g. binary assets) you can stub them out with the "moduleNameMapper" config option.
You'll find more details and examples of these config options in the docs: https://jestjs.io/docs/en/configuration.html
Details:
xxx/node_modules/@babel/runtime-corejs2/helpers/esm/classCallCheck.js:1
({"Object.<anonymous>":function(module,exports,require,__dirname,__filename,global,jest)
{export default function _classCallCheck(instance, Constructor) {
 ^^^^^^

babel-jest 経由で Babel を通したコードなのになぜか ESM版の runtime-corejs2 というコードを通るので、その中に export があって死ぬという怪奇現象。

で、今となってはどこをどう調べたか分からないんだけど、自分が1月に作った設定では以下の記述を足して回避していた。

transformIgnorePatterns: ["/node_modules/(?!@babel/runtime-corejs2)"]

恐らく Babel 7 + Jest ではこういう落とし穴がちょこちょこあるのだろう。

transformIgnore したら export を回避できるというのもよく分からん…。（そしてなぜこうしようと思ったのだ、過去の自分よ）

もしかしたら

Configuring Jest · Jest

transformIgnorePatterns のデフォルト値が <rootDir> 含んでなくてプロジェクト内の node_modules を ignore し忘れてるってことだから明示的に設定したのかな。いやでも新しく足したのも <rootDir> 入ってないけど…。分かってるんならよりよいデフォルトに変えてほしい。

ちなみに最小設定は

rootDir
moduleNameMapper ( Webpack の alias 相当 )
transformIgnorePatterns

でイケるっぽい。

Ruby の WWW::Mechanize のコツが少し分かってきた

Feb 28, 2009

ただし WWW::Mechanize 0.8.x + Hpricot 時代のノウハウ。

オプション一つで取得した HTML とその解析結果のオブジェクトを全ページ保存できるようにしておく
Logger に吐かれる HTTP のログもひとまとめに扱えるようにしておく
保存された情報を穴が開くほどよく見る
- ブラウザではうまくいくけど Mechanize ではダメな場合、HTTP のログはかなり重要なヒントを与えてくれる

以上。

特に mechanize の取得した HTML とその解析結果のオブジェクトを自動で保存しておくようにすると、どこの何の解釈に失敗しているのかを究明するのがだいぶ楽になる。単に Hpricot を使ったときなんかもそうなんだけど、とにかく取得した HTML は即座に保存しておいた方がいいと思う。サーバにも優しいしね。

で、実際これを思ってから2週間後にできあがった、楽できるフレームがこれ。

個人的にはこれ超使える。

ansi8 + M-x customize で emacs22 への準備

Feb 28, 2007

Emacs

やっと M-x customize で色の設定の仕方が分かった。つかまぁ今まで例によって放置だったんだけど。

M-x customize で Faces → Font Lock → Font Lock Highlighting Faces にある。ちゃんとメニューを探して設定していけば .emacs に値が保存されるので安心。よしよし。ちょっと設定がいっぱいあるとめげるけど、まぁ見たままだし、基本的にすぐに反映されるし。

あと起動時のオプションで –color=ansi8 にすると ANSI の 8色だけで使える。つまり、

Emacs 22 を Terminal.app でも安心して使える

わけ。なんか 256 色にしたい人が世の中には意外といるみたいだけど、おらぁそんなものには興味ねーだ。Unicode と svn への対応がよくなって、起動が速いってだけで十分です。

※ ansi8 のビビッドな色で十分満足できるのは OSX + Terminal + 背景色白っていう組み合わせのせいなのかもしれないけど。putty + 背景色黒のときは見にくかったし。（結局 putty でも黒文字白背景にしてた。¹）

Terminal も他のウィンドウと同じ設定の方が目が疲れなくていいと思う。まぁ、自分も SVGA とかの大昔の時代には暗めのブルーを背景にして白文字で使ってたけど、これはこの組み合わせの方が文字が大きく見えて視認性がよく、かつ真っ黒の背景より目が疲れなかったから。今はこんなノウハウ要らないよね。 ↩

PukiWiki のパーサだけ取り出せないか

Feb 28, 2006

PukiWiki/1.4.6読み込み - PC説教講座

ちゅーことで読み始めてみた。まだ目と grep だけで追ってるので漏れてる可能性おおいにあり。今のところパーサの動作とリンクの生成とページの生成がうまく切り離せていないので必要なファイルがやたら多そうに見えるけど、切り離せればもう少し減らせると思う。

最終的にはパーサの動作だけを取り出して markdown みたいに独立したライブラリとして利用できる形を目指したいんだけど、どこまでできるかな。今思っているのは

PukiWiki のパーサだけでテストが書けるようにしたい
PukiWiki のパーサを自作のツールで利用したい
markdown など著名なテキスト整形ライブラリと同じ API を用意する
本当に独立したライブラリにできたらどっかプロジェクトとして登録して自分以外の誰かに管理してもらいたい
- 先に登録するって手もあるけど、成果が出るかどうか分からないのでまだ保留
PukiWiki のパーサを他の Wiki や blog ツールなんかで利用したい

4 から先までの道のりはちょっとヘビーだなと思っている。（その前にたぶん 2 まで行く辺りで一度飽きるだろう:-）何しろ汎用のツールとするにはあまりに global な名前空間を汚してしまっているからだ。（一応あまりに多くの変数に分かれていたのを、ハッシュにして数を減らす方向でバージョンは上がっているんだけど。）

あと、5 を本気で自分でも思っているのかというと実は疑問。¹たぶん 2 を実現したらあとは放り投げて他の人が適当にいじって管理してくれたら嬉しいなくらいにひどいことを考えている気がする。

ていうかスタート段階で「自分よりやる気のある人がいたらおれは喜んでお手伝いに回るよ」とマジで考えているので、どこまでできるかはまったくの未知数です。