First Impressions of Clasp extension for VS Code to manage local development of Google Apps Scripts

The editor for google apps scripts is OK for simple (single file) macros or scripts. But it falls short when you are managing more complex scripts and multiple files. That is where google clasp comes in. Google clasp is an extension for VS code that allows google apps scripts to be updated locally, with changes easily pushed to your It does not replace git, as it does not do version control, but it does do basic syncing well. It has its own .claspignore file like git and uses similar commands – clasp push to send code to and clasp pull to get code down. But it is rather crude – there are no controls and it overwrites everything on with each push. I assume pulls would do the same, but I have not done them and would caution against them. A simple json files clasp.json – holds the scriptID of the remote target and a path to the local “repo”. I have a dev and prob remote target and swap our clasp.json files as needed. Pushing to multiple targets seems to be possible, but I have not implemented it.

I followed this basic guide to get up and running – thank you Learn Google Spreadsheets. As this guide is geared to Mac users and I am running on WSL2 on windows, I had to do a few particular things to get clasp installed.

One clear anomaly that clasp handles is the conversion the .gs file extensions on to .js file extensions in your VS code. I also have a remote git repo connected. The remote git repo works pretty normally, but it does have .js extensions so it cannot be hooked up directly to I would need another repo that connects to the gashub extension for chrome to hold a repo of .gs files. Pretty convoluted, but it works.

I found that having VS Code really facilitates refactoring. I basically treat the as the test server environment and use the watch command (clasp push -w) to make updates quite seamless. All in all a thumbs up.

UPDATE – for those interested – here is my full workflow.

Google Apps Script workflow – with Clasp and Gashub

My love/hate of Cloud Based IDEs.

Having learned modern development late in life, I have relied on cloud-based IDEs for my much of my coding. I started off on which was great until Amazon bought it a few years ago. It was container-based so you could spin up new environments very quickly and access them from any machine. The new version of Cloud9 under AWS still works for me, but I no longer love it. My latest cloud-based IDE is one on ‘training wheels’ – the script editor for Google Apps Script (GAS – such a bad name and acronym).

With GAS, I love the extension of Javascript to the google apps world – the sheets, docs, gmail classes are incredibly robust. And the concept of bounded scripts greatly simplifies authorizations needed to move across apps. The integration with Google Compute Engine – just damn works. And the ability to execute scripts up to 6 minutes (for FREE) is very sweet. I never want to write another line of VB code.

The only real shortcoming is the script editor. While, I did not suffer through the first version, it baffles me why it still has no support of tabs or folders (something my c9 IDE had 5 years ago). Yes it might work for the business users relying mainly on macro-recording. But that is just one use case. With hand-crafted processes, you can create and execute code spread across multiple files, but during coding the UI is only aware of local (single file) references. WTF??? What other code editor only references a single file during coding? Notepad is not a good reference point.

The Script Editor seems to go out of the way to encourage worst practices – putting all of your code in one file with NO version control. Google sheets and docs are amazing at version control – what happened to the script editor? The fact that there is currently no support for local git is a big shortcoming.

I recently solved this lack of version control by integrating a sweet chrome extension – GasHub – that allows even a bounded Google App Script to push and pull to a remote repo – all without a local git. It is very basic – but does the job and simplifies moving code from dev to production. Now with this remote repo integration I want to see if I can move coding to my newly minted local environment (WSL2/Docker/VScode) and even see if GitHub Copilot can help with GAS coding. More to come….