So, letās do something different. If youāre facing a technical challenge, Iām opening up a new way to get direct support. šÆ
How It Works: Fill outĀ this Google Form and share the details of your challenge. Hereās what Iāll need from you:
In this blog post, Dmitry Kostyuk offers Google Apps Script users assistance with their coding challenges. Users can submit their problems through a Google Form, providing details about their problem, relevant code snippets, and any additional comments. Dmitry emphasizes that this is a collaborative learning opportunity, not a code-writing service. Submitted challenges might be showcased anonymously on Dmitry’s blog and social media. Follow the source link for more details.
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!]
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!”
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.
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.
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:
