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.
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.
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.
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.
