Automate publication of your script from development to production easier.
This post by Stéphane Giron provides a CI/CD solution for Google Apps Script, which makes it easy for you to automate the deployment of Apps Script code from a development version to production. The solution uses the Apps Script API to manage versions and streamline the code copying process.
Stéphane has previously created a backup solution for Google Apps Script code, but it lacked version control and multi-file support. This new CI/CD solution addresses these limitations by using the Apps Script API to handle version management and the publication process.
The post includes the necessary code and configuration for implementing this solution. To use this solution you will need to enable the Apps Script API and as well as setting up your project with a standard Google Cloud Platform (GCP) Project.
As a bonus the solution also allows you the option of restoring previous versions of your deployed script, providing a rollback mechanism in case of errors or issues. This solution is lighter weight than other CI/CD setups featured in Pulse, but is easier to set up, providing a practical approach to implementing CI/CD for Google Apps Script projects and enhancing code management and deployment processes.
Recently, I worked on a project with a client who needed to parse XML files and convert them to JSON. Simple enough, right? The catch? These XML files were massive — each containing hundreds or even thousands of trades. Naturally, the first thing I thought of was Google Apps Script’s built-in XMLService. It’s reliable, widely used, and integrates smoothly into Apps Script. But when I ran it on a file with 1,000 trades, the parsing took 45 seconds! That’s painfully slow for an automation process.
[Editor: In a recent blog post, Dmitry Kostyuk has shared a valuable tip for developers working with Google Apps Script. When faced with the task of parsing large XML files, he discovered that the built-in XMLService was causing significant slowdowns. For files containing thousands of records, the parsing process could take an agonizing 45 seconds.
Dmitry’s solution? Using his Apps Script Engine (ASE) and the xml-js NPM library. By making this switch, he was able to achieve a remarkable 10x increase in parsing speed, reducing the 45-second process to only 4 seconds.
If you’re working with Google Apps Script and large XML files, click the source post link to find out how you can give ASE and xml-js a try!]
It has finally happened! Bot Bender 2.0 is now available for installation from the Google Workspace Marketplace. In this post, I will walk you through the steps needed to get to the marketplace.
We’ve shared a couple of journeys to Google Workspace Marketplace publication but this is the first I’ve seen for publishing a Google Chat App. For people who have gone through the process it’s probably a familiar story of back and forth with the Marketplace review team.
In this post Anton Shevchuk shares how his Chat App received multiple rejects due to issues with the location of the support/privacy pages. The moral of the story is to be persistent, and don’t hesitate to push back if you believe the reviewers are mistaken. The post from Anton also outlines the other steps involved, including connecting the Google Workspace Marketplace SDK and configuring app visibility settings.
Welcome to the culmination of my Google Apps Script development journey — the Apps Script Engine. This isn’t just another template; it results from countless hours of refinement, driven by the passion to create the ultimate tool for Apps Script developers. Every ounce of my experience, every lesson learned, has been poured into building this robust, opinionated, yet highly configurable template. It’s designed to empower you to confidently and easily tackle even the most complex projects.
Developing Google Apps Script projects can be a pain, especially when dealing with modern JavaScript features like ES6 modules, the need for fast local development, and integrating NPM modules. The Apps Script Engine Template tackles these challenges head-on, offering:
Seamless ES6 Modules Integration: Finally, you can use this missing JavaScript feature with Apps Script.
Blazing Fast Local Development: Mock functions and promisified google.script.run calls make local development a breeze.
Front-End Framework Support: Includes Alpine.js and Tailwind CSS out of the box, with easy TypeScript integration.
NPM Module Support: Integrate NPM modules into front-end and back-end code effortlessly.
Automated Testing: Set up with Jest, so you can ensure your code works as expected.
CI/CD Integration: Easy integration with tools like GitHub Actions and Cloud Build ensures smooth, automated deployments.
Environment Management: Easily manage different environments (DEV, UAT, PROD) with specific configurations.
[Editor] This post from Dmitry Kostyuk introduces the Apps Script Engine, a template designed to streamline Google Apps Script development. It addresses common challenges by providing seamless integration of ES6 modules, fast local development, support for front-end frameworks and NPM modules, automated testing, CI/CD integration, and environment management.
The template simplifies the setup process, allowing developers to quickly create new projects. It offers a well-structured file system, including folders for compiled files, environment management tools, and source code.
Key features include the ability to use NPM modules in both client-side and server-side code, a custom Vite plugin for bundling, and Git hooks for automated formatting and testing. The template also facilitates environment management, making it easy to deploy code to different Google Apps Script projects.
For web apps, the template supports local development with a development server, and it provides a promisified version of google.script.run for cleaner code even allowing the easy mocking of server-side functions for realistic testing. The template also allows you to build scripts for different environments and even supports deploying libraries to NPM.
This is an incredibly impressive piece of work and Dmitry is encouraging contributions: “Your feedback, fresh ideas, and contributions are not just welcome — they’re what will make this tool even better. Let’s push the boundaries of what we can achieve with Google Apps Script together!”
Project IDX allows you to use all your favourite IDE extensions and themes, but also offers AI assistance through tools like Gemini Code Assist. It also has one-click integration to many Google products such as Firebase Hosting or deploying your app to Cloud Run. A really handy feature of IDX is the ability to share a workspace with a colleague so you can collaborate and develop together in real time! …
This guide will demonstrate how to develop your Apps script code from within Project IDX, and we will even touch on how to enable Google’s AI Code Assistant to get extra help when writing your App scripts.
The current Apps Script integrated development environment (IDE) has several limitations that can hinder collaboration and productivity. One significant limitation is the lack of real-time collaboration. Multiple users cannot simultaneously edit the same script, making it challenging for teams to work together on projects. This can lead to version control issues and conflicts, especially when multiple developers are making changes concurrently.
Project IDX is an experimental cloud-based IDE developed by Google. IDX is designed to make it easier to create, edit and deploy applications eliminating the tasks of configuring development environments for yourself and your team. For Google Workspace developers already doing local code development using VS Code the interface will be familiar as IDX is also built on Code OSS.
As well as being cloud-based IDX has some useful features built-in including GitHub import, extension and a Gemini code assistant. In addition to real-time collaboration (still highly experimental), IDX features a Gemini-powered code assistant with both a suggestion tool and a sidebar chat agent for code where you can discuss your code and get additional help.
This guide by Josh McMurdo demonstrates how you can set up IDX to develop Google Apps Script projects, including the installation of the clasp command line tool to push/pull code to Apps Script projects. As IDX is able to import existing GitHub repositories if you’ve not done local Apps Script development before I recommend Amit Agarwal’s Google Apps Script Starter kit, which can be cloned in IDX from https://github.com/labnol/apps-script-starter.
Once cloned IDX will automatically run the npm install to add all the dependencies. To switch to your own GitHub repository, create a new repo then in the terminal run the following command replacing YOUR_ACCOUNT and YOUR_REPO:
One other note on Josh’s post you don’t need the Add Gemini API step. IDX comes with Gemini code assist enabled, the Add Gemini API step is only required if you want to use Gemini in your Apps Script solution.
A reminder that Google states “Project IDX is in beta. Project IDX is likely to change and is not subject to any service level agreement (SLA) or deprecation policy. The implementation is subject to change without notice and in future releases. Use caution before proceeding to use IDX in a production environment.” IDX also can’t run Apps Script code so you’ll need to use clasp to push back into your Apps Script project and debug there.
As a Developer Advocate for Google Workspace, I live and breathe productivity tools. But even the most tech-savvy among us can have frustratingly simple oversights. My recurring pain point? Forgetting to turn on my Gmail vacation responder to automatically notify people of my absence before heading out of office.
Google Workspace Developer Advocate, Chanel Greco, has shared a clever solution to automate their Gmail out-of-office notification using Google Apps Script. Faced with the recurring problem of forgetting to set up the out-of-office notification, Chanel crafted a script that does the job based on Google Calendar events marked as ‘outOfOffice’.
Chanel’s project not only solves a personal problem but also demonstrates the benefits of Google Apps Script for task customization and productivity. By harnessing the power of Workspace APIs, you can create innovative solutions to automate routine tasks and streamline workflows.
Open-source made me a better developer, and can do the same for you.
TLDR;
This is our final stretch! We’ve navigated through building an Apps Script library, and now it’s time to discuss how you can contribute. Here’s a quick rundown of what we’ll cover:
GitHub Flow: Learn to fork the repository, create a feature branch, and make a pull request.
Guidelines: Tips on ensuring your pull request gets accepted.
Code of Conduct: We won’t delve into this, as respectful behavior is the default expectation.
License: Our library uses the MIT License, which is pretty much the one that lets you do anything you want with the code.
Issues: I will post issues that I consider a priority, but feel free to tackle any of them.
Process: Follow the steps outlined in our CONTRIBUTING.md file.
As a reminder, here are the links to the repo and the NPM page.
But first, let’s talk about what you should do before you open a pull request.
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.
If your automations are not being triggered by Google Form submissions, Pablo Felip’s tip is it could be because your Google Workspace Admin has turned on AppSheet Core Security.
