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:
I tried to see if an AI that’s good at writing could also make smart moves in a game. I chose Battleship and set it up in Google Sheets to play against Gemini, the AI. The result was mixed. On one hand, yes, Gemini could play the game. It followed the basic rules and even managed to sink some of my ships. This was a big deal, especially since it took me a ridiculous number of days of coding to get there, and I nearly gave up at one point.
Dmitry Kostyuk has shared a blog post detailing his experiment pitting the Gemini API against himself in a game of Battleship. As explained by Dmitry while Gemini could follow the rules and even sink some ships, it needed help to avoid basic mistakes, revealing that AI still has room to grow in the realm of strategic games.
Dmitry built the game in Google Sheets and the source code is linked from the post. To guide Gemini, Kostyuk crafted detailed prompts outlining the game’s mechanics and decision-making logic. However, he encountered challenges due to Gemini’s limitations in providing strategic responses. Despite these hurdles, the project yielded valuable insights into prompting techniques for AI decision-making.
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 😉
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.
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!
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. 😅
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.
