MENU
  1. ホーム
  2. gas
  3. VsCodeでclaspの使い方(GASのコードをGitHubで管理する)

VsCodeでclaspの使い方(GASのコードをGitHubで管理する)

gas

GASの管理はclasp経由でGitHubを使うことにしました。

エックスサーバーのお友達紹介プログラム!

claspとGoogle Apps Script GitHubの比較、どっち!?

GASのエディタ、少し微妙なのでやっぱVsCodeでclaspですかね。

claspは本家Googleが開発、Google Apps Script GitHubは最近更新されていない点も考慮材料になりました。

claspを使うことにしました。

スポンサーリンク

VsCodeでclaspの使い方(GASのコードをGitHubで管理する)

すでにGASで開発しており、Githubにデータをpushする流れです。

Google Apps Script APIをオンにする

https://script.google.com/home/usersettings

VsCodeで新規プロジェクト作成。node.js、npmが入っているか確認。インストール。ログイン。

node -v
npm -v
npm install @google/clasp -g
clasp --version
clasp login

ブラウザが立ち上がるのでGmailでログイン > 許可

clasp clone [スクリプトID]

GASエディタを開き、スクリプトIDを取得します。

左上のアイコンをクリックして「プロジェクトの設定」 > 「スクリプトID」をコピー

cloneが成功したらプロジェクトを保存し、リポジトリを作成します。

git initしていつも通り、コミットpushします。

ebookbrain
Githubでリモートリポジトリのファイルを削除他、覚書! Githubの使い方覚書です。Githubでリモートリポジトリのファイルを削除(ターミナル)うっかりとGitHubにプッシュしてしまったけど、リポジトリから外したくなりました。.git…

clasp pushとclasp pullでGASとやりとりします。なお、JavaScriptのファイルになっていますが、気にしなくてOKです。.jsファイルを.gsに変換してGASプロジェクトにpushし、逆に.gsを.jsに変換してローカルにpullします。

.clasp.jsonとappsscript.json

.clasp.jsonファイルとappsscript.jsonファイルは、Google Apps Scriptプロジェクトに関連する重要な設定情報を含むファイルで、ソースコードと一緒にバージョン管理することが推奨されます。

ただし、.clasp.jsonファイルはスクリプトIDを含むため、これを公開すると、他の人があなたのスクリプトにアクセスすることが可能になる場合があります。そのため、プロジェクトがプライベートである場合や、特定のチームや組織内での共有のみを想定している場合は、このファイルを含めてバージョン管理することは問題ありません。しかし、プロジェクトを公開する場合は、スクリプトIDを含む.clasp.jsonファイルを.gitignoreファイルに追加してGitで管理されないようにすることを検討してください。

一方、appsscript.jsonファイルは、プロジェクトの設定（例えば、スクリプトの実行に必要なGoogleサービスの有効化設定や、Webアプリケーションとして公開する場合の設定など）を含むため、これはバージョン管理に含めるべきです。このファイルには、特にセキュリティに影響するような情報は含まれていません。

.claspignoreと.gitignoreで無視するファイルを設定(claspとGoogle Apps Script GitHub)

ひとまず、これで様子見します。なお、node.jsはGitHubで管理するだけなくても大丈夫のようです。

.claspignoreはGASにclasp pushする際に無視するファイル。

**/.env
**/node_modules/
**/.git/

.gitignoreはgithubに無視するファイル。.gitは自動的に除外されるため設定しない。

**/.clasp.json
**/node_modules/
スポンサーリンク

GASでファイル名を変更してもclaspに反映されない

GAS上でファイル名を変更しました。clasp pullをしても直接反映される機能はないため、VsCode上で古いファイルを削除する必要がありそうです。

clasp pull
git rm [旧ファイル名]

そののち、新規ファイルをaddするとRに変換されました。置き換えができました。

スポンサーリンク

claspの開発環境と本番環境を運用

ユーザーにスプレッドシートのコピーを作成して使ってもらうとしよう。

開発環境と本番環境をわけていないと、大元がコピーされることになって大変まずいことになります。さらなる実装をしている最中、動かなくなったタイミングでコピーされたらおしまいです。

だから、もちろんというか、GASも開発環境と本番環境をわける必要があります。

開発から本番に反映させるのはclaspでスプレッドシートを切り替えて、上書きするのが楽そう。ユーザーにURLを告知している場合、新規実装が終わるたびに、新たに複製する方法はURLがかわるため、使えません(外部のリダイレクトサービスを使うなどしたらいけるかもしれませんが、リダイレクトサービスが終了するリスクもあるためなるべく使いたくありません)。

Windows・Macのclaspで開発環境と本番環境を切り分ける

.clasp.jsonは一つのGoogle Apps Scriptプロジェクト（スクリプト）にしか紐づけることができません。つまり、.clasp.dev.jsonと.clasp.prod.jsonの各々、切り替え用のファイルを用意する必要があります。

{
  "scriptId":"<scriptIdはGASのURL内にある!開発と本番は別ものになる>",
  "rootDir":"<rootDirのパスは一緒>"
}

Windowsの場合は最終的にこうまとめるのがよさそうです。

"scripts": {
    "link:dev": "copy .clasp.dev.json .clasp.json",
    "link:prod": "copy .clasp.prod.json .clasp.json",
    "pull:dev": "npm run link:dev && clasp pull",
    "push:dev": "npm run link:dev && clasp push",
    "push:prod": "npm run link:prod && clasp push"
},

Macの場合、copyではなくcpになります。

コマンドはこんな感じで使います。

npm run link:dev
npm run push:dev
npm run link:prod
npm run push:prod

スプレッドシートの変更は開発から本番にコピペで移植する方法が楽です。ただ一括でやるならスクリプトを書いた方がよさそうですね。

MacとWIndowsの自動切り替え

scriptsにこのような設定を追加します。

"link:dev": "node -e \"process.platform === 'win32' ? require('child_process').execSync('npm run link:dev:win') : require('child_process').execSync('npm run link:dev:mac')\"",

開発と本番で共有されるものとされないもの

最後に本番環境をURLを閲覧者で共有する方法がよさそうです。

  • 共有されるもの：スプレッドシート、スクリプト
  • 共有されないもの：スクリプトプロパティ、デプロイのデータ、修正履歴

確認方法

  • スプレッドシートの修正履歴：ファイル > 変更履歴 > 変更履歴を表示
  • スクリプトデータのデプロイ：デプロイ > デプロイの管理

スクリプトプロパティは一緒のものを使うはずなので、再度いれなおしになります。

スポンサーリンク

claspのエラー

filelist.map is not a function

filelist.map is not a function

linkしてpushする際にでました。

clasp loginで、gmailでログインする際にチェックをつけていないことが原因っぽいです。

rootDirのパスも見直してみましょう。

スポンサーリンク

GASのデプロイ!ウェブアプリのURLでできること

必要になるケースに次のようなものがあります。

  • ウェブサービスとしての利用
  • 外部サイトとの連携

参考になれば幸いです。

スポンサーリンク
gas
よかったらシェアしてね！
  • URLをコピーしました！
  • URLをコピーしました！

コメント

コメントする