gas-fakes provides robust support for testing your Google Apps Script projects that use shared libraries. This allows you to develop and test your code locally, even when it has complex dependencies, by simulating the Apps Script library environment.
There are three primary ways to make your libraries available in the gas-fakes environment:
- Automatic Loading: From your project's
appsscript.jsonmanifest. - Custom Manifest: By providing a manifest object directly in your code.
- Manual Loading: From the command line interface (CLI).
If your project already has an appsscript.json file with libraries listed in the dependencies section, gas-fakes can automatically load them. This is the most seamless method as it uses your existing project configuration.
gas-fakes provides a global object, LibHandlerApp, in the execution environment. To load the libraries from your project's manifest, simply call LibHandlerApp.load(). It's best practice to wrap this call in a check for ScriptApp.isFake, so your code doesn't produce errors when running on Google's actual servers.
The load() method will:
- Read your
appsscript.jsonmanifest file. - Find all the libraries listed in the
dependencies.librariesarray. - Fetch the code for each library.
- Recursively perform the same process for any libraries that your dependencies use.
- "Inject" all the libraries into the global scope, making them available for your script to use.
Let's say your appsscript.json looks like this:
{
"timeZone": "Europe/London",
"dependencies": {
"libraries": [{
"userSymbol": "TestLib",
"libraryId": "1zOlHMOpO89vqLPe5XpC-wzA9r5yaBkWt_qFjKqFNsIZtNJ-iUjBYDt-x",
"version": "1"
}]
}
}Your script main.js can then load and use the library:
// main.js
// Best practice: Only run this in the gas-fakes environment
if (typeof ScriptApp !== 'undefined' && ScriptApp.isFake) {
// Load all libraries from the project manifest
LibHandlerApp.load();
}
function myFunction() {
// Now you can use functions from TestLib
TestLib.hello();
}
myFunction();You can run this with gas-fakes, and it will automatically fetch and include TestLib:
npx gas-fakes -f main.jsYou can also pass a manifest object directly to LibHandlerApp.load(). This is useful for testing specific library configurations without modifying your project's appsscript.json.
Here's an example of loading a library using a custom-defined manifest object.
// test-script.js
// Best practice: Only run this in the gas-fakes environment
if (typeof ScriptApp !== 'undefined' && ScriptApp.isFake) {
const mockManifest = {
dependencies: {
libraries: [
{
libraryId: '13JUFGY18RHfjjuKmIRRfvmGlCYrEkEtN6uUm-iLUcxOUFRJD-WBX-tkR',
userSymbol: 'bmPreFiddler',
},
],
},
};
LibHandlerApp.load(mockManifest);
}
function runFiddler() {
// Use the library loaded from the mock manifest
const result = bmPreFiddler.PreFiddler().getFiddler({id:'xxx', sheetName:"yyy"}).getData();
console.log(result.slice(0, 5));
}
runFiddler();For quick tests or situations where you don't want to create a manifest, you can manually specify libraries using the --libraries flag with the gas-fakes CLI.
The --libraries flag takes an argument in the format Identifier@Source.
Identifier: This is the name your script will use to refer to the library (e.g.,MyLib).Source: This is where to get the library code. It can be:- A path to a local JavaScript file (e.g.,
./libs/my-lib.js). - A URL pointing to a raw JavaScript file.
- The script ID of a deployed Google Apps Script library.
- A path to a local JavaScript file (e.g.,
You can provide the --libraries flag multiple times to load multiple libraries.
Imagine you have a local library file sample-lib.js:
// sample-lib.js
function sayHello() {
console.log('Hello from the library!');
}And a script main.js that wants to use it:
// main.js
function runTest() {
// MyLib is available because we are loading it via the CLI
MyLib.sayHello();
}
runTest();You can run your main script and link the library using this command:
npx gas-fakes -f main.js --libraries "MyLib@sample-lib.js"The output would be: Hello from the library!
| Service | Classes | Methods | Completed | In Progress | Not Started |
|---|---|---|---|---|---|
| Base | 17 | 127 | 93 | 2 | 32 |
| Cache | 2 | 11 | 7 | 4 | 0 |
| Calendar | 13 | 273 | 273 | 0 | 0 |
| Charts | 29 | 238 | 37 | 0 | 201 |
| Content | 3 | 16 | 16 | 0 | 0 |
| Document | 47 | 1032 | 880 | 12 | 140 |
| Drive | 8 | 164 | 124 | 8 | 32 |
| Forms | 41 | 504 | 266 | 0 | 238 |
| Gmail | 6 | 168 | 167 | 0 | 1 |
| HTML | 6 | 39 | 34 | 0 | 5 |
| JDBC | 20 | 753 | 311 | 0 | 442 |
| Lock | 2 | 7 | 7 | 0 | 0 |
| 1 | 5 | 0 | 0 | 5 | |
| Properties | 4 | 11 | 6 | 5 | 0 |
| Script | 16 | 84 | 22 | 0 | 62 |
| Slides | 76 | 1288 | 1005 | 0 | 283 |
| Spreadsheet | 108 | 1771 | 1301 | 19 | 451 |
| URL Fetch | 2 | 13 | 12 | 0 | 1 |
| Utilities | 5 | 59 | 59 | 0 | 0 |
| XML | 14 | 149 | 142 | 0 | 7 |
| Total | 420 | 6712 | 4762 | 50 | 1900 |
- release notes
- gas fakes intro video
- getting started - how to handle authentication for Workspace scopes.
- readme
- apps script parity
- omlx setup
- Natural Language Automation with Gemini Skills & MCP Server - new skills-based agent approach.
- Add agent skills to gf_agent
- gf_agent documentation - instructions for the Gemini CLI automation agent and MCP server.
- gas fakes cli
- local add-on and webapp development with gas-fakes
- Bringing the webapp home
- Local development example code
- github actions using adc
- github actions using dwd and wif
- ksuite as a back end
- msgraph as a back end
- resurrecting scriptDb repo
- Resurrecting ScriptDb – nosql database for Apps Script
- gas-fakes in serverless containers
- apps script - a lingua franca for workspace platforms
- Apps Script: A ‘Lingua Franca’ for the Multi-Cloud Era
- running gas-fakes on google cloud run
- running gas-fakes on google kubernetes engine
- running gas-fakes on Amazon AWS lambda
- running gas-fakes on Azure ACA
- running gas-fakes on Github actions
- jdbc notes
- Yes – you can run native apps script code on Azure ACA as well!
- Yes – you can run native apps script code on AWS Lambda!
- initial idea and thoughts - how it all started
- Inside the volatile world of a Google Document
- Apps Script Services on Node – using apps script libraries
- Apps Script environment on Node – more services
- Turning async into synch on Node using workers
- All about Apps Script Enums and how to fake them
- colaborators - additional information for collaborators
- oddities - a collection of oddities uncovered during this project
- named colors
- sandbox
- senstive scopes
- using apps script libraries with gas-fakes
- how libhandler works
- article:using apps script libraries with gas-fakes
- named range identity
- Workspace scopes with local authentication
- sharing cache and properties between gas-fakes and live apps script
- gas-fakes-cli now has built in mcp server and gemini extension
- gas-fakes CLI: Run apps script code directly from your terminal
- How to allow access to Workspace scopes with Application Default Credentials
- Supercharge Your Google Apps Script Caching with GasFlexCache
- Fake-Sandbox for Google Apps Script: Granular controls.
- A Fake-Sandbox for Google Apps Script: Securely Executing Code Generated by Gemini CLI
- Power of Google Apps Script: Building MCP Server Tools for Gemini CLI and Google Antigravity in Google Workspace Automation
- A New Era for Google Apps Script: Unlocking the Future of Google Workspace Automation with Natural Language
- Next-Generation Google Apps Script Development: Leveraging Antigravity and Gemini 3.0
- Modern Google Apps Script Workflow Building on the Cloud
- Bridging the Gap: Seamless Integration for Local Google Apps Script Development
- Next-Level Google Apps Script Development
- Secure and Streamlined Google Apps Script Development with gas-fakes CLI and Gemini CLI Extension
- Secure and Conversational Google Workspace Automation: Integrating Gemini CLI with a gas-fakes MCP Server
- A Fake-Sandbox for Google Apps Script: A Feasibility Study on Securely Executing Code Generated by Gemini CL





