Clasp もろもろまとめ

ソフトウェア開発 プログラミング -> 言語 -> TypeScript

Clasp について、書き殴りに近いですがまとめです。

Clasp について

1. $ clasp login

Google アカウントにてログインをして、Clasp 用の権限を得る。

$ clasp login

これにより、~/.clasprc.json が作成される。

2. $ clasp clone

既存のプロジェクトを持ってくるために $ clasp clone する。

なお、スプレッドシート の新規作成や App Script の新規作成を行うには $ clasp create を実行する（実際はほとんどやる機会はないと思う）。

$ clasp clone スクリプトID

このコマンドを実行すると以下の 2つ のファイルが作成される。

  • .clasp.json
  • appsscript.json

「スクリプトID」はスプレッドシートの URL から取得できる。

3. 得られた 2つ のファイルの取り扱いについて

  • .clasp.json は .gitignore する
    • 開発者ごとの情報が入るし、秘匿情報も入るから
  • appscript.json は触る必要はない

4. スクリプトの拡張子を .ts に統一する

  • .js と .ts の拡張子が混在している時は .js は $ clasp push の対象外になる
  • .ts に統一する

5. tsconfig.json を追加

公式ドキュメントどおりに最低限の tsconfig.json を追加する。

{
  "compilerOptions": {
    "lib": ["esnext"],
    "experimentalDecorators": true
  }
}

6. .claspignore を設定する

  • .claspignore を必要に応じて設定する。
  • ホワイトリスト形式なので、サブディレクトリを新たに作った際には .claspignore に追記する必要がある

7. $ clasp push してみる

  • 適当にコードを変えて $ clasp push してみる
  • Webページ側で確認し、変更が反映されていれば OK

注意点など

Clasp だけを使うプロジェクトを作ること

  • たとえば、非エンジニアの方が編集する既存の js (gs) と共存することは可能だが、かなりの注意を要する必要がある
  • まず前提として clasp push した場合は「リモートの GAS を全部まっさら空っぽにしてから push される」
  • なので、以下の手順を 必ず ふまないと先祖返りする危険性が常にある
    • 手元で既存の js には触らない
    • 共存する .js は push する直前に常に pull して最新版にする
    • 共存する .js は .claspignore で除外設定をして常にそのままの状態で push する
  • 上記を実現するのは大変に面倒で、たとえばつねに pull を挟んで push するとなると開発速度が落ちる*1
    • 「他の誰も GAS を触っていないと確定している時間帯を選んで開発する」のような前時代的なことになる
    • みんなが Clasp を使っていてもこの問題は起き得るが、GitHub の default ブランチ が最後の砦となってくれる
  • 現実的には、共存せずに、素直に GAS のプロジェクトを分けるべき

みんな Clasp を使うこと

  • Clasp を用いるプロジェクトではみんな Clasp を使うこと
    • Web 画面で見られるものはデプロイされたコードであり、手で触るものではない
    • つまり、本番コードは Clasp 経由でないと作成・修正・削除などはできない*2

みんな Clasp で みんな TypeScript を用いること

  • 前項と同じで、デプロイされたファイルは js (gs) なので、それを pull してくるとビルドされた js が手元に届き、それは人間がいじるものではない
    • デプロイしたファイルを手元に持ってきて継続開発はしないのと同様、全ての開発する人の起点は GitHub の TypeScript となる

.clasprc.json や .clasp.json を使い分ける方法

  • clasp コマンド ではオプションを指定することで .clasprc.json や .clasp.json を変更できる
    • 複数アカウントや複数プロジェクトを扱うことも可能
      • Clasp の仕様上、複数のディレクトリを作ってプロジェクトを分けることになる
  • package.json の scripts: において --auth や --project オプションで個別に設定ファイルを指定して使い分ける、というのがいい
$ clasp --help
Usage: clasp <command> [options]

clasp - The Apps Script CLI

Options:
  -v, --version                               output the current version
  -A, --auth <file>                           path to an auth file or a folder with a '.clasprc.json' file.
  -I, --ignore <file>                         path to an ignore file or a folder with a '.claspignore' file.
  -P, --project <file>                        path to a project file or to a folder with a '.clasp.json' file.
  -h, --help                                  display help for command

複数ファイルを用いて import / export 的なことをする場合にはどうしたらいいか？

  • 全体を namespace Hogehoge {} でくくる*3
    • メソッドや変数の定義の前に export を付与する
  • 呼び出す側は接頭語（レシーバ）に Hogehoge を指定する
    • 階層フォルダ構造も取ることができる
      • Webコンソール上のファイル名は、スラッシュが単なる文字となって平たくなる
    • 関数名や変数名の名前は完全にグローバルなので衝突に注意する
      • つまり、階層構造にしたとしても、Webコンソール上（内部）では単に「見た目」が変わるだけ
  • 具体例は以下のとおり
namespace Foo {
  export const greeting = () => {
    Logger.log('Hello, World!')
  }
}
function bar() {
  Foo.greeting()
}

webpack を使えばいいのでは？

それなりにエコシステムが揃っている が、

  • ビルドして push したら人間はほぼ手を触れることができない
    • ローカルでデバッグ（テスト書く）のが必須
  • そこまでの規模のことを GAS でやろうとすることを見直すべき

と考えるので、オーバーエンジニアリングと思っている。

ログ出力の方法

  • Logger.log('foobar') または console.log('foobar')
    • 2つの方法には違いがあるのは有名だが、clasp を使うような人たちなら console.log を使っておけばほぼ問題ない

変更を検知して自動で push をさせる方法

複数人開発をしている場合は他の人の内容を上書きしてしまう可能性があるので注意。

$ clasp push --watch

Webコンソールをリロードしなくても clasp push は反映されているか？

  • されている
  • 同じメソッドの実行を繰り返しながら開発しているようなときは、わざわざリロードしなくていい
    • $ clasp push --watch を実行させながらトライアンドエラーをサクサク繰り返せる

package.json の "scripts" をうまく使う

  • 例えば .clasprc.json や .clasp.json を使い分けるとき
    • package.json の scripts プロパティに実行オプションの記述を押し込んで、npm や yarn コマンド経由で簡潔に実行できると楽
      • 自分の場合は "c": "npx clasp -A .clasprc.json" と定義しています
  • あまりにごちゃごちゃするようならばシェルスクリプトでもよい

最新の API の型ファイル（の中身）はない

  • 例えば AnalyticsData とかの型
  • 仕方ないので直前の行に // @ts-ignore と書いて赤い波線が引かれないようにする

テストは書けない

  • 場合によってはガリガリの手動で書くことはできる
  • 現実的には、トライアンドエラーを高速に回すプリントデバッグがいい

ファイルの順番依存がある

  • Webコンソール画面に並ぶ順番によっては期待どおりに動作しないことがある
    • たとえば、他のファイルの変数や関数を利用しようとしたときに undefined をレシーバにしてしまうことがある
    • 一応 filePushOrder というプロパティを .clasp.json に書く方法がある
    • コードをバンドルしてしまう というやり方もある
    • つらい…

*1:watch も使えない

*2:これは良くも悪くもであり、非エンジニアは参画できないというのは一つの大きな特徴になる

*3:Clasp では namespace はむしろ推奨される

Powered by はてなブログ