🤔

Zennでのコンテンツ管理でのトラブル事例

2 min read

4ステップでGithubからZennに記事を公開してみる(トラブルシューティング付き) | Zenn を閲覧しまして、自分が遭遇した事例も紹介したほうがよさそうかな、と小記事にしました。

Zennコンテンツ管理リポジトリの改名

状態

自分は最初からZennをリポジトリ管理しているのですが、最初のリポジトリ名は zenn-article というものでした。

これは記事だけいれればよいか、くらいから名付けましたが。

  • booksないから本は入れない予定なんだね、とslackで突っ込まれた(一応そのうちやってみたくはあった)。
  • 単数なので微妙

というのもあり、改名しました。 tsuyoshicho/zenn-articles-and-books

問題

改名自体はGitHub上でやるだけですので、問題はなく行えました。
ただ当然といえば当然なのですが、連携しているリポジトリとしては見なされなくなっていました。

ですので、連携解除後、再度このリポジトリを対象として連携しました。
(このあたりは最初にある別記事を参照していただくとわかりやすいです)

これによって記事やそのLike状態がどうなるか心配だったのですが、引き継がれたようでなによりです。

結論

リポジトリの改名はさほど負担ありません。

Zennコンテンツ管理リポジトリの管理

管理

さて、せっかくリポジトリを作ったので、ここでの記事追加をブランチ->PR->マージの流れでやりたいと思い整備します。

詳細はリポジトリを見てもらうとして、GitHub workflowで textlint で記事をチェックするようにしています。
また、Zenn CLIを含めて関係パッケージも増えますので、 Renovateでの更新を設定しています。

問題

逆に初期化の際ちょっとサボって自分で作ったため、npx zenn init をしておらず、ちょっと変になってた部分もありました。
別箇所で init し、その内容を反映して整形しています。

結論

ちゃんと手引きに沿って初期化してから始めるのがよいでしょう。
また、リポジトリ管理にしているなら、GitHub workflowは活用の幅が広いです。

Zennコンテンツのslug

さて、リポジトリで管理しているのでslugは任意のものが付けられます。

問題

最初は記事の順序性なんてないし、明確な記事の内容が分るものでよいだろう、と思っていました。
ですが、記事の内容って陳腐化というか古いがゆえに参考にならなくなる、というのはあるのでslugに日付が入っていると明確でよさそうと思いなおしました。
(某slackでの会話でも「日付があったほうがよいのでは」という指摘を別の記事でされました)
see Zennの記事をほんの少しだけ楽に作成できるVimコマンド | Zenn

そこで、記事ファイルをrenameしました。

ここで更新したファイル名をマージしたところ、旧来のslugでの記事(バックエンドなし)と新規が併存するようになりました。
古い記事は削除しています。

これで元の記事のLikeやらは消えました。
まあほとんどなかったので、少数の方にはもうしわけないっですが、生みの痛みということでご了承ねがいたく。

結論

slug設計は計画的に。

Zennコンテンツのslug2

リポジトリ管理で新規記事を作るのは zenn new:article ですが、これを npm run new-article にしてあります。

問題

ただこれで作るとslugが乱数です。
独自情報が面倒でコマンド定義したのにオプションを付けるのも面倒です。

結論

実際の所、リポジトリに入れたファイルがどうなるか、です。
ファイル内にこの乱数なslugと関係のある部分はないです。

ですので、コミット前に必要な名前へリネームすればOKでした。

結び

参考になれば幸いです。

Discussion

ログインするとコメントできます