ファイルを 0.intro.md とかにしたい。

[Jxck]

以下の対応ありがとうございます。これでまた便利になりました！
https://zenn.dev/zenn/articles/deprecated-book-deployment

さっそくこれを試そうとしたところ、自分の場合は完全にファイル名を変えてしまうと、連番がなくなりディレクトリ内でファイルの順序がぐちゃぐちゃになるので、先頭に連番は残したいなと思い、こうしました。

• 0.intro.md
• 1.foo.md
• 2.bar.md

これだけでも今まで 0.md が使えなかったから intro を入れると節の番号とファイル番号がずれなくなることと、ファイル名からどの節かわかりやすいという改善が得られます。

で、これを zenn-cli で preview したら思ったとおりに動いたので、デプロイしてみたら、デプロイにに失敗しチャプターが全部消えました。(ログを見ると 0.intro.md で 0.md を探しているみたいです)

最初のエントリを読み直すと

👆 各チャプターのファイル名には好きな文字列（a-z0-9とハイフン-の1〜50字の組み合わせ）を使い、チャプターの並び順はconfig.yamlで指定します。

とあったので、 1_intro.md などに変えてみたのですが、こんどは preview で以下のエラーが出ました。

TypeError: configYamlChapters.map is not a function
...

で結局元に戻しました。戻して思ったのが、自分としては 0.md だけ許容されればそれでもよかったかもしれません。

要望としては

• n_name.md が valid なのかどうか知りたい
• n.name.md という命名も対応してもらえるとより嬉しい
• それが URL に反映されるなら n. を消して /intro にしてもらえるとなお嬉しい
• n.md も非対応にせず (n > 0) で残してもらえるとそれもありかも

といった感じでした。

[catnose99]

詳しくありがとうございます。

n_name.md が valid なのかどうか知りたい

現在対応しているのは、①「n.md」 ②「slug.mdとしてchapter.yamlで並び順を指定」のみになります。
「n_name.mdとしてchapter.yamlの指定なし」の場合にはエラーになる…というのが現在の仕様です。
（CLIはエラーをうまく出せていなかった状態です）
内部的にはconfig.yamlにchaptersが指定されているかどうかによりデプロイの仕方（旧モードか新モードか）を切り替えています。
　

n.name.md という命名も対応してもらえるとより嬉しい

検討してみます。対応する場合、
①config.yamlでchaptersが指定されている場合 => chaptersの指定通りにname.mdを読みに行く
②config.yamlでchaptersが指定されていない場合 => n.name.mdを読みに行く
という形になると思います。
※ ②では仰る通りURL維持のため、n.name.mdのうちnameだけをURLに含めることになります。

n.md も非対応にせず (n > 0) で残してもらえるとそれもありかも

後からチャプターを差し込んだときにURLがずれてしまうのは読み手がリンクを貼ったとき / 無料の本のチャプターがGoogleにインデックスされたとき等に混乱を招くと思うので、この方式はやはりゆくゆくは廃止したいと思っています。この点に関して、完全にリリース時点での考慮が足らなかったと反省しています。

上記の① + ② の両方に対応、というのが理想的な形だと思います。
あとは内部的な処理が複雑になってしまう部分をどうするか、というシステム上の問題ですね…（現在もけっこう複雑になってしまっており…）

[Jxck]

ありがとうございます。

「n_name.mdとしてchapter.yamlの指定なし」の場合にはエラーになる…というのが現在の仕様です。

現状は chapter を yaml に指定しても preview でエラーになってると思います。

①config.yamlでchaptersが指定されている場合 => chaptersの指定通りにname.mdを読みに行く
②config.yamlでchaptersが指定されていない場合 => n.name.mdを読みに行くという形になると思います。
※ ②では仰る通りURL維持のため、n.name.mdのうちnameだけをURLに含めることになります。

これなら、ローカルでファイルの順をチャプタの順にしつつ、チャプタが増減しても URL が変わらないのでいいと思います！

[catnose99]

私の環境で、ディレクトリ構造を以下のようにして…

books
└── my-awesome-book
    ├── config.yaml
    └── 1_example.md

config.yamlの中身を以下のようにしてみたのですが

title: "テスト"
chapters:
  - 1_example.md

エラーが発生せず、ちょっと原因が分かっておりません。
お手数をおかけして申し訳ないのですが、config.yamlの中身をこちらに貼り付けていただくこと等は可能ですか？

[catnose99]

各チャプターの内容に繋がりがある本の場合、ディレクトリ上で順番を見やすいというのは重要になると思うので、来週の平日に②の対応を試みることにします。

自分向け仕様メモ

• config.yamlにchaptersがない場合は②の方式でのデプロイを行う
• ②の方式で、旧仕様（n.md）の互換性も保つ
• チャプターファイル名がn.name.mdもしくはn.mdとなっていない場合、デプロイをスキップする
• n.name.mdの場合、チャプター番号を決めるposition=n、スラッグ=nameとする
• n.mdの場合、チャプター番号を決めるposition=n、スラッグ=nとする
• 各チャプターのデプロイ完了後、デプロイが行われなかった既存チャプターは削除する（このようにせずに旧仕様の互換性を維持しようとすると同内容のチャプターが複数並んでしまう可能性がある）

イレギュラーへの対応

• 同スラッグのファイルが複数存在する場合（1.example.mdと2.example.md）、どちらかのみがデプロイされる
• 同番号のファイルが複数存在する場合（1.foo.mdと1.bar.md）、どちらが先に来るのかはシステムでは責任を持たない
• 番号飛びがあっても（1.foo.mdと3.bar.mdはあるが、2.**.mdが存在しないような場合）zenn.dev上でチャプターが欠損して表示されることのないように「nの値=チャプター番号」とするのではなく「nの値=チャプターの並び順を決める際に使う数値」とする

[Jxck]

エラーが発生せず、ちょっと原因が分かっておりません。お手数をおかけして申し訳ないのですがconfig.yamlの中身をこちらに貼り付けていただくこと等は可能ですか？

了解です、なにか勘違いだったかもしれないので後ほど再現して貼り付けます。

[Jxck]

うーんできましたねぇ🤔 (preview も build も)

https://zenn.dev/jxck/books/origin-anatomia/viewer/0_intro

すいません、こっちに関しては無視してください🙇‍♂️

[catnose99]

ご確認ありがとうございます！

[catnose99]

②の方式でもzenn.devにデプロイができるようになりました。
（CLIの方の対応はこれからです）

[Jxck]

おー素晴らしい！ありがとうございます！

[Jxck]

適用してみました。思ったように動いてます！
https://zenn.dev/jxck/books/origin-anatomia

[catnose99]

早速ありがとうございます！
2020/10/24にリリースしたZenn CLIでも②の形式でslugを正しく扱えるように動くようになりました。
（まだ「①の方法を使用してください」とメッセージが出ますが、無視していただいてOKです）

[catnose99]

TODO

• ドキュメントに②の管理方法を追加
• ②のケースでのCLIのアラートメッセージを非表示に

[lacolaco]

@catnose99 この機能を使ってみようと思ったのですが、自分の本で適用しようとすると不都合がありました。
私の本は1冊の中でいくつかのセクションを分けていて、セクションごとにチャプターを管理しやすいようにもとは次のような命名をしてchapters で順番にならべていました

- 1-1-first-refactoring.md
- 1-2-separate-components.md
...

これを新しい n.slug.md のフォーマットに変えようと思い、n の部分でセクションを次のように表現したところ、デプロイ時にチャプター数のエラーが出ました。

実際に存在するチャプターは10数個ですが、nの部分だけでたくさんチャプターがあると判定されたように見えます。

このエラーは解消できますか、という質問もあるのですが、そもそもこのようにチャプターがいくつかのグループを持つユースケースはどのように表現されるのを想定されていますか？

[catnose99]

@lacolaco
遅くなりすみません。

実際に存在するチャプターは10数個ですが、nの部分だけでたくさんチャプターがあると判定されたように見えます。

仰る通りです。実際に保存したチャプター数を見るように変更しようと思います。

そもそもこのようにチャプターがいくつかのグループを持つユースケースはどのように表現されるのを想定されていますか？

チャプターをいくつかのセクションに分ける方法については、現時点では実現できておらず今後やりたいと思っている部分です。理想的にはbooks/slugの下にもう1階層ディレクトリを作れるようにしたいと思っています。

books
 .
└ books
   └─ 本のスラッグ
       ├ config.yaml
       ├ section1
       | └─ チャプターファイル
       ├ section2
         └─ チャプターファイル

ただ、どのような構成にするべきか/どう実装するべきかについてまだ正解が掴めていない状況です。
少し時間はかかると思います。お待ちいただけるとありがたいです。