apps-script-starter: Vite, Jest and clasp for Google Apps Script in VS Code

Why a bundler at all in the Apps Script world

The starter kit provides a boilerplate for developing Google Apps Script projects using modern JavaScript, ES6+, and a local development environment. Its purpose is a development workflow that includes code bundling, linting, testing and deployment.

The problem it solves is specific to Apps Script. The platform's own editor is browser based, it has no package manager, and the runtime is not Node. Every Apps Script file is a separate file in Google's infrastructure, and there is no way to import a module from a local file. Historically that meant writing everything in one file, or emulating modules with a global namespace.

The answer here is a build step. You write modular code in a src/ directory, Vite bundles it into a form the platform accepts, and clasp pushes the bundle. The README states that Vite will automatically transpile your code to a format compatible with the Google Apps Script V8 runtime.

The directory layout makes the boundary explicit. The main source code is in src/, with src/index.js as the entry point, src/html/ for the HTML files that make up the user interface, and src/server/ for the server-side code. The build output goes to dist/, and the .clasp.json configuration specifies scriptId and rootDir pointing at it, so what clasp uploads is the bundle rather than your source tree.

That separation is the point. You get a normal repository with normal tooling, and the constraint of the platform is handled in one place rather than in every file.

Four commands to clone, install, create and push

The getting started path is short and each step is a separate concern.

The prerequisites are Node.js, which includes npm, and a Google account.

Cloning uses degit rather than git clone, which means you get a clean copy without the repository history.

npx degit labnol/apps-script-starter my-project
cd my-project

Dependencies are installed with npm install, and then clasp is authorised against your Google account.

npx clasp login

The project itself is created bound to a Sheet, and clasp creates the Sheet and the bound script project in your Drive as a side effect.

npx clasp create --type sheets --title "My Apps Script Project" --rootDir ./dist

Note the --rootDir flag, which matches the rootDir in .clasp.json. That is how the new project and the bundler output are connected.

The daily loop is then three npm scripts. The dev script watches and rebuilds, the test script runs the suite, and the deploy script builds and pushes.

npm run dev

npm run test

npm run deploy

The deploy script is described as building your project and then using clasp to push the bundled code to your Google Apps Script project, and in package.json it is defined as npm run build followed by npm run upload, with upload being npx clasp push.

The README also recommends the labnol Extension Pack for Visual Studio Code for working with Apps Script files in the editor, and points to a step-by-step video tutorial for getting set up.

The testing limitation, stated up front

This is the sentence that decides whether the starter kit is useful for your project.

You cannot directly test code that has dependencies on Google Apps Script services, for example SpreadsheetApp or Logger. You will need to mock these services in your tests.

Every Apps Script project has at least one of those dependencies, and a good number have SpreadsheetApp at the centre of their logic. The testing setup, then, covers the parts of your code that are pure logic, and the parts that touch the platform are covered by mocked services. That is the same compromise any serverless platform forces, and it is a real constraint on how much confidence a green test run gives you.

The mechanism around it is otherwise conventional. Jest is the test framework, the test script is node --experimental-vm-modules node_modules/jest/bin/jest.js, and the experimental vm modules flag is there because the package is type: module and Jest needs the flag to load ES modules. Test files sit alongside the files they test with a .test.js extension.

The dependency list shows the Google-specific pieces. @types/google-apps-script gives the editor type definitions for the platform's global services, eslint-plugin-googleappsscript provides lint rules for the platform, and @google/clasp is the official command line tool. There is also a single runtime dependency, apps-script-oauth2 pulled from the googleworkspace GitHub repository, which is the standard helper for the OAuth dance that a Workspace add-on needs when it has to act as the user.

That last entry is the tell. The starter kit is aimed at add-ons with a user-facing OAuth flow, not at internal scripts.

The config files that define what gets pushed

The configuration section lists five files, and together they are the contract between your source tree and the platform.

appsscript.json is the manifest file for your Google Apps Script project, and you use it to specify dependencies, OAuth scopes and other settings. This is the file that determines what the add-on is permitted to do and what consent screen the user sees. A repository root also has scopes.md, which is a project-specific document about scopes rather than a config file.

.clasp.json is the configuration for clasp, specifying the scriptId and rootDir for your project. The scriptId is the identifier Google assigned when the project was created, and rootDir is where clasp finds the code to push.

vite.config.js customises the build process. The devDependencies also include vite-plugin-static-copy, which is what moves the HTML files and other static assets from src/html/ into the build output alongside the bundled JavaScript. A Vite build that emitted only a script bundle would produce an add-on with no interface, so the static copy step is load-bearing rather than decorative.

.prettierrc and eslint.config.js handle style, and the eslint config is assembled from a set of plugins rather than a single config: eslint-plugin-prettier, eslint-plugin-simple-import-sort, eslint-plugin-import-x, eslint-plugin-jsonc and eslint-config-prettier, on top of @eslint/js and globals. The postbuild script then runs npx prettier --write dist/**/*.js, so the bundled output that gets pushed is formatted as well as your source.

There is also a .claspignore and a .prettierignore at the root, and a .vscode/ directory for editor settings.

From a tutorial template to a toolkit used in production

The most informative claim in the README is about who uses this.

The starter kit is used by Digital Inspiration for building popular Google add-ons including Gmail Mail Merge, Google Forms Notifications and Document Studio, all three of which are named with their Workspace Marketplace links.

That is a stronger signal than any feature list. Those are add-ons with real user numbers on the Marketplace, and they run on a toolchain that consists of a bundler, a linter, a formatter and a test runner. It means the setup decisions in this repository have been exercised against production add-ons, including the awkward parts like OAuth scopes and the manifest.

The project is developed by Amit Agarwal and Digital Inspiration, and the topic list names gmail, google-apps-script, google-sheets and google-workspace, which matches what the add-ons do.

The release history tells the other half of the story. Version 1.0, named the Rhino Release, is from 2020-02-06, and version 1.1, named the Webpack Version, is from 2025-04-10. So the project spent its first five years on one runtime and one bundler, and moved the build tool recently. The current package version is 15.0.0, which is a different numbering scheme entirely, and the last push was on 2026-04-14.

Those two releases also explain the Rhino and Webpack names. Rhino was the old Apps Script JavaScript runtime, and V8 replaced it. The transition was a breaking change for every Apps Script developer at once, and a starter kit that had to change its build tool was the natural place to absorb that.

What a starter kit cannot decide for you

A boilerplate answers a set of questions, and it is worth being clear about which ones it leaves open.

It does not decide your architecture. The src/ layout with index.js, html/ and server/ is a starting point, and a project with an add-on UI will need to grow beyond it.

It does not handle the OAuth flow for you. The apps-script-oauth2 dependency is the standard helper library, but scopes.md and FUNCTIONS.md in the repository are the project-specific documents, and understanding what your add-on will ask the user for, and how you write to a sheet, is still work the starter kit cannot do.

It does not solve the environment problem for Google Workspace add-ons published on the Marketplace, where the review process and the manifest scopes are a separate project from the code.

And the two things worth checking before you commit to it are the ones the README is least explicit about. First, the toolchain is pinned to recent versions, Vite at 8, ESLint at 10, Jest at 30 and Prettier at 3, so the floor on your Node version is higher than it was. Second, the test script uses node --experimental-vm-modules, an experimental flag, which means the test setup is not on the stable path of the toolchain.

Neither is a reason not to use it. Both are reasons to read the package.json before you commit, which in this case is a short file.

Editorial conclusion

apps-script-starter suits a developer who wants to write modern JavaScript against Google Apps Script and keep the code in a normal Git repository with linting, formatting and unit tests, because the Vite plus clasp pairing removes the older clasp-only workflow that most Apps Script projects still use. It is the wrong tool for a small script with a couple of functions, since a bundler and a build step are more machinery than the job needs, and it is the wrong choice if you need to test anything that depends on a live Apps Script service, because those calls have to be mocked. Before you adopt it, read the scopes.md and FUNCTIONS.md files in the repository, since the OAuth scopes and the server function layout are where a project like this most often goes wrong.

Frequently asked questions

Official sources

1. labnol/apps-script-starter on GitHub
2. License: MIT
3. Project website
4. README
5. Releases