Google Apps Scriptを取り巻く環境のおさらい

claspを利用した開発がそれなりにまともに動くと言ってよい状況になりそうなので、前提の情報をまとめておく。

これまでのApps Scriptの開発はパッチワークだった

以前 Google Apps Script + Node.jsで簡単なツールを作ってみた - あーありがち(2015-10-31) や Google Apps Script開発をもうちょっとモダンにしてみる - あーありがち(2017-05-27) で取り上げた際には以下のような状況だった。

  1. 実行は Script Editor 上で手作業で行うかそれを実現する Web API を publish しておく
  2. ログは Script Editor 上で表示するか BetterLog - Google Apps Script Examples などを利用して Spreadsheet 上で確認する
  3. Drive API を利用して Standalone Script を local <-> remote ( Google ) で同期が可能
    • いわゆる local 開発が可能と言われていた部分はここ。この local 開発の成果物を VCS で管理できるという話
  4. テストの自動化 は 1 と 3 を組み合わせて local 開発しつつ remote でそのまま動かす Home | QUnitGS2 のようなアプローチか、リンク先で挙げたように stub/mock しまくるかのいずれか
  5. 4 をどこまで頑張るかは置いておくとして GitHub ポチーで merge してリリースすることはできる
  6. GAS側のバージョン（Herokuのdeployment IDのようなもの）管理は手動

なんとか、あれとこれを組み合わせればできんことはないですよ、というレベル。しょっちゅうやっているならともかく、たまにしかやらないとまぁ忘れてしまうし、手間が掛かる割にそこまでよくなっていないようにも見える。

結局、手元でやりたいことの多くは API アクセスではなくて純粋なロジックの部分だけだったりするのでそこには Node.js 流の開発手法を持ち込みたいけど、いざ実行して確認するためには GAS 固有の手法もちゃんと頭に入れた状態で行う必要があって、やってることはそんなに複雑でもないはずなんだけど妙に頭のリソースを使うものになってしまっていた。

※ また Google Apps Script開発にstaging環境を用意してContinuous Deployment - あーありがち(2017-06-19) で説明したように、production と staging などの情報をいわゆる普通の Web ホスティングのように環境変数で設定するようなことはそんなに簡単じゃないので、逆に CI までその情報を引っ張ってきて CI 上でどうにか頑張って判別して前処理を行うなどの涙ぐましい努力が必要だった。この部分は Cloud Build を利用することで多少マシにはなる。また Cloud Build を前提にするのであれば、環境変数しか利用手段のなかった秘密情報の部分については Secret Manager を利用することでかなり管理しやすくなる。これは Apps Script 周りの話ではないが、Google のインフラ全体が改善されたことで得られたメリットなので補足として挙げておく。参考は あーありがち - GCPのサービスアカウントの鍵を作って持ち出す必要がなくなった

Apps Script APIが登場した

2018年頃の話だったかな。

これからは clasp やでぇ、試してみたでぇという話で溢れかえった。

実際にはツールとしての clasp 以前の話として API が追加されていて、そっちが重要になってくる。大きく変わった部分は以下の二つ。

  • Apps Script API が登場し、Apps Script Dashboard というもので Apps Script の情報を俯瞰できるようになった
  • Apps Script Project というリソースを整理し、これを GCP Project と紐づけることで他のアプリと同じように Stackdriver で実行の状況を管理できるようになった

Apps Script API  |  Google Developers

これまでは Apps Script の情報を取得するのに Drive API しか使えなかったため、Apps Script だけを抜き出した画面などは存在しなかったが、Apps Script API の登場でだいぶ管理しやすくなった。

また GCP Project と紐づけることができるようになったことで、これまで Script Editor 上でしか確認できなかったログの情報、エラーの情報を他の GCP Project と同じように Stackdrive で管理できるようになった。これは非常に大きい。やっとまともにログを扱えるようになったと言っていい。

加えて script の run が API で可能になった。つまり Web API の publish という無理やりな技は不要になった。

そしてclasp

この Apps Script API を利用する CLI として clasp が登場した。これまでバラバラだった

  • script の読み書きとそれに必要な credentials の取得
  • script の実行
  • script の GAS 上でのバージョン管理
  • project の deploy ( add-on として配布できるようにするとか )

などがすべて手元の CLI から可能になっており、開発体験は非常に良好になったと言える。

加えて clasp push の際には grant/ts2gas: A function that transpiles TypeScript to Google Apps Script. を利用した TypeScript から Apps Script への変換も自動で行われるようになったので、clasp を利用した Apps Script の開発はモダンな書き味での読み書きを提供してくれる。

※ ついでになってしまうが 2020年に V8 runtime が登場したことにより、Script Editor 上でもそのままモダンな書き味で Apps Script を読み書きできるようになった。Script Editor 自体のシンタックスハイライトなどの対応レベルはまだ改善の余地があって、それは2021年に行われるようだが、ts2gas が ES3 に変換を行うことで Script Editor 上では非常に古めかしく刺々しいコードになってしまうという問題はいずれ解消されるかもしれない。（個人的には ts2gas を使わない方法にしてしまう方がよいと思っているのであまり関係ないが。）

cf. Apps Script’s new V8 runtime | Google Cloud Blog

More