AppsScriptPulse

Deploying an Apps Script Library Part 5: Deploying as a Native Apps Script Library

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.

Here are the links to the repo and the NPM page.

Let’s get started by bundling our code.

Source: Deploying an Apps Script Library Part 5: Deploying as a Native Apps Script Library

Deploying an Apps Script Library Part 4: Essential Developer Tooling

 

 

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.

Source: Deploying an Apps Script Library Part 4: Essential Developer Tooling

Deploying an Apps Script Library Part 3: JSDoc vs TypeScript

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.

Source: Deploying an Apps Script Library Part 3: JSDoc vs TypeScript

Deploying an Apps Script Library Part 2: Source Code and Project Structure

 

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.

Source: Deploying an Apps Script Library Part 2: Source Code and Project Structure

Ever felt like you’re bringing a knife to a gunfight? That’s me coding without `console.table()` in Google Apps Script. Here’s what I did about it.

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:

| Sheet Name | Last Row |
| ---------- | -------- |
| Sheet1     | 513      |
| Sheet2     | 27       |
| Sheet3     | 50       |

But as fate would have it, Google Apps Script doesn’t include a console.table() function, or even a Logger.table()

Source: Ever felt like you’re bringing a knife to a gunfight? That’s me coding without console.table() in Google Apps Script. Here’s what I did about it.

How to Write to a JDBC Database with Google Apps Script: My Adventure with a Pesky Character Limit

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 😉

Source: How to Write to a JDBC Database with Google Apps Script: My Adventure with a Pesky Character Limit

Creating your on preview ink Smart Chips in Google Docs: The Untold Potential of Apps Script

 

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.

Source: Previewing Links with Smart Chips: The Untold Potential of Apps Script

One Code to Rule Them All: Deploying Editor Add-Ons Across Google Sheets, Docs, Slides, and Forms

Mastering Google Apps Script: Deploy Once, Run Everywhere 🚀

What’s The Issue? 🤔

Building add-ons with Google Apps Script is akin to owning a magic wand for distributing your application. And if you’re like me, you’ve probably created an army of internal add-ons for clients and personal use, especially those sweet editor add-ons. But here’s the catch: every time you deploy your add-on, you need to specify the script ID and the deployment version for each context (Docs, Sheets, Slides, and Forms). Keeping up with 4 different files isn’t just tedious; it’s like trying to juggle flaming swords while on a unicycle 🙃. But don’t worry, there’s a better way!

Source: One Code to Rule Them All: Deploying Editor Add-Ons Across Google Sheets, Docs, Slides, and Forms

Master Google Apps Script UIs — Part 9: Elevating Your Game with TypeScript 👾

Taking JavaScript to the Next Level with TypeScript for your Google Apps Script Projects

A Warm Welcome Back to the Series 🎉

Hey there, and welcome back to our hands-on series on mastering Google Apps Script UIs! Now, if you’re serious about JavaScript, it’s high time we chat about TypeScript. TypeScript is a superset of JavaScript that brings static typing to the game. It’s like JavaScript put on its best suit and turned into a more organized, reliable version of itself. 😎

The reason a lot of developers are switching to TypeScript is because it can catch errors at compile-time, making debugging less of a headache (it’s like having a personal assistant who checks your work for mistakes so you don’t look silly later). In this part, we’ll let the Emojibar project rest (it’s earned it, after all!), and we’ll switch over to a different repository I frequently use as a boilerplate for my projects. This boilerplate is a work in progress, so don’t be surprised if it changes faster than you change your socks. 😅

Source: Master Google Apps Script UIs — Part 9: Elevating Your Game with TypeScript 👾

Master Google Apps Script UIs — Part 8: Deploying Across Multiple Environments

Streamlining Your Development Workflow with Multiple Deployment Environments 🚀

Kickoff: Marching Towards Deployment

Welcome back, dear coders! Our Emojibar is not just a fun prototype anymore — it’s a full-fledged tool ready to be unleashed into the wild. But before we let it run free, we need to get our house in order, or in our case, our environments. And no, I’m not talking about recycling, though you should be doing that too!

Professional development calls for setting up different environments — it’s a bit like having different outfits for different occasions. At the very least, you’ll want to have a development environment where you experiment and break things (yes, it’s encouraged!), a User Acceptance Testing (UAT) environment where your users can give your app a test drive, and a production environment, the red carpet where your app shines.

Source: Master Google Apps Script UIs — Part 8: Deploying Across Multiple Environments