Everyone says use Google Apps Script libraries for easier maintenance — I found a better way. Here’s why NPM modules might change the game for you too.
Last time, we covered how to deploy our library as a native Google Apps Script (GAS) library using Vite, GitHub Actions, and clasp. This setup is efficient, but there’s a notable drawback to using Apps Script libraries.
According to the official guide: “Warning: A script that uses a library doesn’t run as quickly as it would if all the code were contained within a single script project. Although libraries can make development and maintenance more convenient, use them sparingly in projects where speed is critical. Because of this issue, library use should be limited in add-ons.”
Apps Script is not known for its speed, being a free runtime. Slowing it down further by using native GAS libraries is generally not advisable. Therefore, I prefer to avoid native GAS libraries whenever possible.
Instead, it’s much more efficient to bundle your dependencies directly into your source code, similar to how it’s done in Node.js. This is where NPM modules and Vite come into play.
In this post, we’ll cover:
Which NPM modules are compatible with Google Apps Script and which ones are not.
How to use NPM modules in your Apps Script projects.
Forget everything you know about deploying Google Apps Script, because the typical ‘Deploy’ button is not part of our strategy.
TLDR;
In the previous posts in this series, we focused on preparing our tools and setting the stage. We reviewed our project’s functionality, explored the project structure, and delved into the source code. We also discussed the pros and cons of using JSDoc versus TypeScript and covered essential developer tooling.
Today, we’re finally getting to the fun part—deploying something! We’ll start by deploying our library as a native Google Apps Script library. But there’s a twist: we will do it the proper CI/CD way, avoiding the typical “Deploy” button in the online IDE.
Side note: I always avoid the online IDE as it feels like my hands are tied when I use it.
Instead, we’ll use Vite with a custom plugin to bundle our library and GitHub Actions to handle the deployment.
In this series about deploying Google Apps Script libraries, Part 2 dove deep into Test-Driven Development (TDD) and highlighted jest as my go-to tool for outstanding outcomes. Now, let’s broaden our toolkit with additional essentials that not only elevate our development standards but also make our codebase more welcoming to collaborators.
First up, we’ve got ESLint. Linting, for those unfamiliar, is the process of running a program that will check your code for potential errors.
Next, we introduce Prettier, which takes our code and formats it into a structured style that you define. Think of Prettier as the stylist of your codebase, making sure everything looks ‘pretty’ and readable by cleaning up those messy or inconsistent styles left behind.
We also employ Husky, a tool for managing git hooks. Git hooks are scripts you can set to run before or after events like commits, push, and receive. Husky ensures that tools like ESLint, Prettier and Jest run every time you commit changes, helping catch issues before they hit production.
These tools are indispensable not just for solo developers but also for teams looking to contribute to the library. By maintaining consistent, pre-defined high standards of code hygiene, we ensure that our library remains robust, clean, and maintainable.
Prerequisites: You should be familiar with git, an essential skill for any developer. If you’re not, I recommend checking out the beginner’s guide at FreeCodeCamp. Additionally, being able to code locally and understanding clasp is crucial. If you need a refresher on this, visit my earlier post on setting up your local environment. Once you’re set, we can dive into making our development process even smoother and more efficient!
Here are the links to the repo and the NPM page again.
About a year ago, a notable shift occurred in the developer community when SvelteKit made the decision to transition from TypeScript to JSDoc, specifically stating that TypeScript was not the ideal choice for developing libraries. This move definitely raised some eyebrows and stirred the pot among developers. Initially, I was skeptical, perceiving it as a regression rather than progress. TypeScript was even featured in one of my previous blog posts as a recommended tool. However, this decision began to resonate with me over time, leading me to adopt a similar approach in Google Apps Script. The reasons for this shift are manifold, with some being universally applicable and others specific to the peculiarities of Apps Script.
Here are the links to the repo and the NPM page again.
Let’s dive into why TypeScript was chosen in the first place and what has changed to endorse JSDoc over it.
Following up from last week, we get into how I built the table() method in our ConsolAS class, using test-driven development (TDD). This is a cool way to make sure everything works perfectly by testing each part before we fully build it. We’re aiming to make it work just like the console.table() function in Google Chrome, which is pretty handy.
Here’s the scoop: While tinkering with a project, I needed a way to pinpoint the last row of data in various sheets — essentially to catch any “orphan” values lurking there. Typically, something like console.table() would be the hero of the day, allowing me to effortlessly display data like so:
Apps Script class that provides equivalent methods offered by the built-in DriveApp, but that does not require use of full ‘/drive’ OAuth scope (which is a “Restricted” scope”). Instead, uses only these Recommended (non-sensitive) and/or Sensitive scopes
When you use OAuth 2.0 to get permission from a Google Account to access their data, you use strings called scopes to specify the type of data you want to access on their behalf. For Google Workspace Add-on developers wanting to distribute your app in the Google Workspace Marketplace one consideration is only using the scopes required for your app. In the case of Google Drive a number of the scopes are classified by Google as “restricted”. To use “restricted” scopes there is an enhanced verification process, which requires Cloud Application Security Assessment (CASA) by an independent security assessor, which come at a cost and can be time consuming.
ReDriveApp is a new Apps Script community library published by Dave Abouav which makes it easier for developers to use reduced recommended scopes for integrating with Google Drive. As explained by Dave:
The built-in DriveApp service is an easy and powerful way to interact with Google Drive in your Google Apps Script projects, which is why so many developers make use of it. It’s one downside is that it forces your project to use the full ‘/drive’ OAuth scope, which is a “Restricted” scope.
In many cases though, projects don’t really need the full /drive scope for common tasks, and the Recommended /drive.file scope is sufficient. This allows your project to create new files, and open existing files if authorized by the end-user via the Drive Picker. Using it also avoids the aforementioned security review, and is less alarming to users when authorizing your app.
ReDriveApp is still work-in-progress and not an official Google project. There are a number of methods that still need to be implemented, but the project is open source and can be contributed to on GitHub. If you are planning or have already developed a Marketplace Add-on that has stalled due to enhanced verification for restricted scopes it could be worth looking at and contributing to this library.
Google Apps Script is often used to pull data from various services via HTTP requests. However, these requests sometimes fail due to network or service issues. The default behavior of UrlFetchApp is to throw an exception, which you have to catch. Otherwise, the script execution will be interrupted. We often need more: send the request again instead of failing. There is no built-in way to do retries in Apps Script. Solution – To solve this problem and not copy-and-paste code snippets from project to project, I created FetchApp – an open-source Google Apps Script library
This looks like a useful little library which puts a nice wrapper around the UrlFetchApp service. The wrapper includes options for: retries, delays (including exponential backoff), custom callbacks, code hints and automatic logging. The supporting post includes lots of documented code snippets for using the library which should make it easier to implement. A very handy drop in replacement if you are having to communicate with more sensitive API endpoints. The code is also on Github if you want to take a look at how the library is coded.
In this report, I would like to introduce the sample scripts for using Microsoft Docs files with Document service, Spreadsheet service, and Slides Service of Google Apps Script.
Users have had the ability to edit MS Word, Excel and PowerPoint files directly in Google Drive for a number of years, Google making this the default behaviour in 2020. There aren’t currently any APIs or Apps Script services that enable you to edit these particular document types. This however hasn’t stopped Kanshi Tanaike for developing and sharing the MicrosoftDocsApp library which makes it possible to edit MS Word, Excel and PowerPoint files using the same methods as you would for Google Docs, Sheets and Slides.
The library is able to do this by converting the Microsoft files into the Google equivalent, before using the MS export options in Google Drive to replace the original files. This does create some limitations highlighted in the post. In particular, the original documents are overwritten and not directly edited which means any incompatible feature as part of the Microsoft to Google conversion will be lost. Regardless of these it’s a clever approach and might be useful for users who have to keep feet in both the Google and Microsoft worlds.
Using Google Gemini API with Google Sheets to create personalized mail merges. An exploration in generative AI ‘function calling’
Google latest generative AI solution, Gemini, includes the capability to declare functions that the LLM can use in it’s response. The response includes the name of the function and the parameters the script needs to run the function.
The function isn’t executed by the LLM, but run with your code, which creates really interesting opportunities for Google Apps Script solutions. In particular, given user identity and authorisation is an integral part of Apps Script and how it integrates with other Google services it means solutions like personalised mail merges can be created in a couple of lines of code.
Follow the source link to find out more about function calling and exploring Gemini’s capabilities with data in Google Sheets.
