This report introduces the method for managing the histories of the Google Apps Script project.
On August 23, 2023, the project history has been implemented in the new IDE of Google Apps Script. In the current stage, the users can see the history of the previously deployed script version. … In the case of the classic IDE, the users had been able to see the previously saved script version regardless of the deployment and just the save of the script. This is not implemented in the new IDE.
In August 2023, Google updated the online Apps Script Editor adding a feature which lets you view previously deployed script versions and compare them to the current script version. A current limitation the history is limited to versioned deployments. As noted in this source post from Kanshi Tanaike, deployments require several steps and you have to remember to go through the process. To make the process easier Kanshi has published a ScriptHistoryApp library, which can be used to create a custom web interface for making your own Apps Script project version history. Perhaps more usefully you can also manage snapshots of your script projects by fetching a URL. This makes it easy for you to either regularly save a project on a timed trigger or an event based mechanism.
I recently faced a frustrating issue when writing data to a CloudSQL database with the JDBC class in Apps Script. I kept getting the following error:
Exception: Argument too large: SQL
I also observed that it only happened when my SQL query reached a certain length. I considered breaking it down into multiple queries, but I was still puzzled 🤔 because I was only sending a few dozen kilobytes of data.
Now, the thing is, the official documentation could be more helpful; even though the solution is there, it needs to be better explained. So, I turned to StackOverflow. There was a discussion on this exact topic, but to my surprise, I was still waiting for an answer. Until, well, I wrote it 😉
The key takeaway for Google Apps Script users is unlike Google Docs which can automatically save a version history of a document, Apps Script project history requires the user to use deployments (Deploy > Manage deployments) to create a version should you want to see get a highlights or code changes between the current and previous versions. This will be less of an issue if you are using Google Apps Script to deploy web apps, Workspace Add-ons or libraries, which already use deployments, but for other situations like container bound scripts you might want to get into the habit of using the Deploy button to create a version.
The eagerly awaited project history capability for Google Apps Script in now rolling out. The feature is similar to the version history functionality found in other Google Workspace editors like Google Docs. As well as being able to see differences between the current and previous versions you can restore your script project to that point. Unlike Docs, Sheets and Slides there is currently no ability to ‘make a copy’ or ‘name a version’. My experience when using the Drive revisions data is that Google may merge revisions to save storage space.
Project IDX is a browser-based development experience built on Google Cloud and powered by Codey, a foundational AI model trained on code and built on PaLM 2. It’s designed to make it easier to build, manage and deploy full-stack web and multiplatform applications, with popular frameworks and languages. Project IDX is also built on Code OSS, so it should feel familiar no matter what you’re building.
Where will the online Google Apps Script go next? Google have announced it’s latest experiment in browser based IDEs in the form of Project IDX. A key feature of Project IDX is integration with AI tools to help developers:
With Project IDX, we’re exploring how Google’s innovations in AI — including the Codey and PaLM 2 models powering Studio Bot in Android Studio, Duet in Google Cloud and more – can help you not only write code faster, but also write higher-quality code. Currently, Project IDX has smart code completion, an assistive chatbot, and contextual code actions like “add comments” and “explain this code”. Our AI capabilities are in their very early days, and we’re working on making IDX AI even better at helping you as you work.
Project IDX isn’t publicly available but there is a waitlist you can join from the website. Give Project IDX is an online IDE it will be interested to see if features are rolled into the Script Editor. At the very least as you can develop offline using tools like clasp it open up interesting opportunities for Apps Script development.
Alright, folks, we’re talking about something quite hot off the press in the realm of Google Apps Script — “Smart Chips.” This feature is available within Google Docs and can build previews of pasted links using the Card Service. Think of it as a little preview window of what lies beyond the link — a sneak peek, if you will. 🕵️♂️
Editor: Smart chips are a recent feature in Google Workspace that help you quickly insert information into your Docs and Sheets. They can be used to insert people, places, dates, and more. It’s also possible for Google Workspace developers to publish their on ‘Preview links’ smart chips as Workspace Add-ons. In this post from Dmitry Kostyuk you can learn about publishing your own smart chips and some creative ways to get the data you need using Google Apps Script.
Welcome back, code wranglers! Today, we’re diving into the world of developer dependencies that make developing projects more efficient than a coffee-fueled coder on a deadline. 🚀 You can find the complete source code in the part-04 branch of the Github repository. Also, feel free to mess around with this demo spreadsheet and play with Emojibar. I’ll be updating it with every new blog post!
What Are Dev Dependencies?
Dev dependencies are like your car’s GPS: they’re not necessary for the car to run, but they sure make getting to your destination a lot easier! 🗺️ They’re modules necessary for the development and testing processes of a project, but not for its production runtime environment. They’re not bundled with the source code and help automate tasks that would otherwise make you pull your hair out.
There’s a long standing issue with triggers installed programmatically by other triggers, that was kind of fixed last year, but users are still reporting problems, at least in certain locations (Japan, India and others). The issue in short: triggers installed programmatically would not be created, or fail systematically.
In many cases this affects add-ons (and, to be noted, the issue still persists when testing them, see Testing details); I had a slightly different scenario: a webapp that, when executed (doGet), would install a time based trigger for the user executing the script.
This article provides two solutions to an annoying issue and unlocks many possibilities for programmatically installed triggers.
Get security and peace of mind by backing up your Google Apps Script files to Google Docs and trigger for continuous backup.
We’ve featured a couple of methods for restoring Google Apps Script code in Pulse, but most of these rely on recovering a deployed version of the script. Stéphane Giron wields his Apps Script hammer and skilfully demonstrates how you can use Google Docs and it’s built-in version history as a way of keeping a backup copy of your code.
Apps Script has turned down the legacy integrated development environment (IDE) in favor of the redesigned IDE that launched in December 2020.
Google have announced the updated Apps Script editor will replace the legacy experience by Q4 2022. Whilst the new IDE was a huge step forward there are some core features from the old Script Editor, which will hopefully make it into the new IDE before Q4. The ones I hear most often are access previous script versions and search/replace across project script files. For the later in the meantime I recommend looking at the Black Apps Script Chrome extension. Whilst this extension primarily enables a true dark mode it also lets you search across script files.