claspを使ってGASにデプロイする話のつづき。
前の記事でpush時に自動でTypeScriptをトランスコンパイルしてくれるということを書いたのだが、実際にゴリゴリ長いコードを記述するとなるとコード整形などで保守性を良くしておきたくなるもの。 というわけで今回はtslintやpretterもう少し環境を整える話。
作業の前にアップデート
前回から結構間があったので念の為アップデート。v1.5.3→v2.0.0
$ sudo npm install -g -u @google/clasp
/usr/local/bin/clasp -> /usr/local/lib/node_modules/@google/clasp/src/index.js
+ @google/clasp@2.0.0
$ clasp
Usage: clasp <command> [options]
clasp - The Apps Script CLI
Options:
-v, --version
-h, --help output usage information
Commands:
login [options] Log in to script.google.com
logout Log out
create [options] Create a script
clone [options] [scriptId] [versionNumber] Clone a project
pull [options] Fetch a remote project
push [options] Update the remote project
status [options] Lists files that will be pushed by clasp
open [options] [scriptId] Open a script
deployments List deployment ids of a script
deploy [options] Deploy a project
undeploy [deploymentId] Undeploy a deployment of a project
version [description] Creates an immutable version of the script
versions List versions of a script
list List App Scripts projects
logs [options] Shows the StackDriver logs
run [options] [functionName] Run a function in your Apps Scripts project
apis [options] List, enable, or disable APIs
list
enable <api>
disable <api>
help Display help
setting|settings [settingKey] [newValue] Update <settingKey> in .clasp.json
* Any other command is not supported
パッと見で気づくとこだとapis系が増強されてるのとsettings系が追加されてる感じ。
ということで以下作業を進めていく。
ソースのディレクトリを変更
これから色々とnodeモジュールを導入していくわけだが、それらスクリプト本体でないものまでpush時にアップロードされてしまうのはよろしくない。.claspignoreに記述するという手もあるが、シンプルにディレクトリを掘ってしまうのが無難だろう。今回は仮にプロジェクトディレクトリ下にsrcディレクトリを設ける。
cloneしてくる前だったりそもそも作り始めるタイミングなら--rootDirオプションで指定すれば良い。
$ clasp clone XXXXXXXXXXXXXXXX --rootDir ./src
一方、すでにローカルにpullしてきている状況の場合はsettingコマンドを用いてrootDirを設定する。
$ clasp setting rootDir src Updated "rootDir": "" → "src"
もっとも、これだけだと設定を変更しただけで、すでにあるファイルまでは移動してくれない。既存のファイルを手動で移動させるor再度pullしてこよう。
$ mkdir src $ mv appsscript.json src/ $ mv *.js src/ $ mv *.ts src/
TSLintの導入
そんなこんなでやっと本題。まずはコードの望ましくない記述を指摘してくれるTSLintを導入する。
$ npm init -y $ npm install typescript tslint -D
先にinitしておく。
$ node_modules/tslint/bin/tslint --init
package.jsonにlintコマンドを追加。
"scripts": {
"test": "echo \"Error: no test specified\" && exit 1",
"lint": "tslint --fix 'src/**/*.{ts,js}'"
},
生成されたtslint.jsonを開き、実用上console.log等が塞がれてしまうと辛いのでルールを追記しておく。
"rules": { "no-console": [false] },
これで以下のようなコマンドでlintを実施できる。
$ npm run lint
Prettierの導入
どうせだったらチェックだけじゃなくて良い感じに整形してくれると良いよねーってことでPrettierも導入。
$ npm install prettier tslint-config-prettier tslint-plugin-prettier -D
先程のtslint.jsonにprettierを呼び出せるように記述を加えていく。
{ "defaultSeverity": "error", "extends": [ "tslint:recommended", "tslint-config-prettier" ], "jsRules": {}, "rules": { "no-console": [false], "prettier": true }, "rulesDirectory": ["tslint-plugin-prettier"] }
Lintの実行
そんなわけで実際に使ってみる。以下のようにわざと汚いコードを書いてみる。
$ cat src/Code.ts
function func1(){
const dict={a: 1,b: 2,c: 3,d: 4};
}
コード的には動くけど、インデントやらスペースやらめちゃくちゃ。で、早速実行。
$ npm run lint
> tslint --fix 'src/**/*.{ts,js}'
Fixed 2 error(s) in src/Code.ts
ファイルを開くと、見事に整形されている！
$ cat src/Code.ts
function func1() {
const dict = { a: 1, b: 2, c: 3, d: 4 };
}
実用上、lintを実行した上でデプロイしたりバージョン管理するのが良いだろう。
Makefileを作っておくと便利
最近のマイブームなのがMakefileによる作業の簡略化。今回もこれを使ってみる。
以下のようなMakefileを設けておいて、make一発でlint実行とpushまで行えるようにすると便利だろう。
default: push
lint:
npm run lint
push: lint
clasp push
deploy: push
clasp deploy
open:
clasp open
logs:
clasp logs --open
.PHONY: lint push deploy open logs
以上でコードをきれいな形に保つ開発環境を整えることができた。やはり生でES5を書くのと比較するとTypeScriptの文法は単純に書いていてストレスが少ないし、バッチ的なものを運用する上では型があると格段に保守性が良くなる。
JavaScriptプログラマのための 実践的TypeScript入門 (アスキー書籍)
- 作者: 川俣晶
- 出版社/メーカー: 角川アスキー総合研究所
- 発売日: 2014/06/03
- メディア: Kindle版
- この商品を含むブログ (1件) を見る
ただ、ちょっと辛いのがGASのJavascriptランタイムが古すぎてTypeScriptからトランスコンパイルされた先のコードでも動かない記述が結構あること。使用頻度が高いところだとArray.prototype.find()とかObject.assign()あたりが使えないのがしんどい。
まあこれもランタイムが新たなものになることがアナウンスされてるので、おいおいより良くなっていくだろう。
Modern Javascript – A common request is updating the JavaScript syntax to be able to use more modern features and libraries. At Next ‘18 it was announced that this would be supported by moving to ECMAScript 2017 scripting-language specification.
