TypeScript typings cause very high memory usage in tsc

When importing googleapis within a TypeScript project, tsc takes up a large amount of memory (500 MB+). This appears to be the case because when googleapis is imported, it imports the type definition files for every single API that Google has, even if only a single API (e.g. drive_v3) is required.

Environment details

OS: Ubuntu 20.04 LTS
Node.js version: 10.20.1 (LTS)
npm version: N/A (We don't use npm instally, but we use yarn v1.22.4)
googleapis version: 51.0.0
typescript version: 3.8.3

Steps to reproduce

Please see reproduction repository here: https://github.com/yjwong/tsc-googleapis-memory-usage

Essentially, even just a simple:

import { google } from 'googleapis';

Will result in high memory usage from tsc.

There is also a related StackOverflow question:
https://stackoverflow.com/questions/56599477/typescript-googleapis-surge-in-memory-used

Workaround

Import the APIs individually, like so (example is Google Drive SDK v3):

import { drive_v3 } from 'googleapis/build/src/apis/drive/v3';
import { AuthPlus } from 'googleapis-common/build/src/authplus';

Short of splitting the module up into their own sub-modules, I doubt there's anything that we could really do about this :/

@JustinBeckwith

@JustinBeckwith I'm guessing that would be related to this issue? #806

If splitting the module up to individual packages is going to be a massive undertaking, I think it would be also helpful if there will be an officially supported way of including individual modules, like the workaround above. I'm concerned that for example, AuthPlus would be an internal implementation detail.

Requiring an additional 500 MB of memory per build job using tsc just to use one of Google APIs is quite a huge ask. (The alternative is to use the REST APIs directly, but we lose type checking)

Yeah, there are a lot of tradeoffs here to be sure. We used to dynamically discover available APIs in the module at runtime, but this badly broke things like webpack and rollup. We can't really reduce the raw volume of TypeScript types on a per-API level, because that gets us in trouble with correctness.

The good news here is that we're actually pretty close to having split modules (20% left is 80% of the work), and it's possible you can take advantage of what we have so far. You can cd into any API dir, and run npm pack to get a single standalone module with just that API. For example:

cd src/apis/drive
npm install
npm pack

That actually should give you a self contained module that only contains what you need. I know this ain't ideal, but it does provide a way to get the isolated module.

I had trouble packing the relevant packages.
Eventually I mapped googleapis package types to an empty types file and the memory issue was resolved.
Of course, no types support this way.

@rommguy

@rommguy are you able to import the APIs that you're using individually, as @yjwong suggests. I believe this is partially a documentation problem, as we should be documenting this as the recommended approach.

@bcoe

@bcoe I wasn't able to do as @yjwong recommended.
I'm using version 59.0.0
Example -

const { google } = require("googleapis");
const iam = new google.iam("v1");

Now I tried importing like so -

import { iam } from "googleapis/build/src/apis/iam";
const iam = new iam("v1");

Getting an exception: TypeError: google.iam is not a constructor
I'm guessing I imported the wrong property or from the wrong path, but I have no idea what should be the correct way.

@rommguy

@rommguy I believe you can use an API directly like this:

import {iam_v1 as v1} from "googleapis/build/src/apis/iam/v1";
const client = new v1.Iam({});

Let me know if this works for you, and if it's an approach that's viable, we can work on making this easier to do.

@bcoe

@bcoe Thank you, I really appreciate your help!
I'm using several of the apis, and I think it would be best if there was some documentation of how to import each service separately.
I'll try what you suggested about the iam API.

@bcoe

Thanks @bcoe for the workaround.

This OOM problem is a serious issue for adoption of this library! I wasn't able to tsc a small project (using 512mb memory, which should be enough) that uses 1 api (sheets) due to this.

Sheet-specific workaround for others that view this:

import { sheets_v4 as v4 } from "googleapis/build/src/apis/sheets/v4";

const sheets = new v4.Sheets({});

@sgb-io

@sgb-io @rommguy we have now also started publishing individual modules for any libraries in googleapis that don't have an alternative client:

Give these a shot, rather than the hack I proposed?

I'm was shocked to find this issue in my app after a ton of digging. I feel like there should be a major callout to use the individual modules since it's written in typescript.

If you need to reduce startup times

doesn't describe why to use the smaller libraries. It caused my app to crash due to memory no matter what i tried if i imported anything.

This is still a huge issue. It's really hard to pin down since tools like PNPM and Turborepo do not tell you that the process quit because of a memory surge. Most NodeJS devs do not know that 512m is the memory limit for Node processes.

Can you guys please add some exports to your package.json? Things like googleapis/youtube and googleapis/oauth? Having devs find the build artifacts in the path is a problem since the path values could change at any time.

For now you can use NODE_OPTIONS to force a higher limit. I know my project goes close to 2GB.

NODE_OPTIONS="--max-old-space-size=4096" pnpm tsc --project ./tsconfig.json

@matsko

Just bumping this, similar to the point that @matsko brought up, it was really difficult to pin down that this was the issue that was causing it. Exports to core aspects such as oauth would be super helpful. Many thanks!

I've created a dedicated feature request for the googleapis/oauth request here: #3695

I ran into this problem when using Jest: importing the big library causes Jest to fill up the entire system memory (32GB in my case) within seconds because it starts 16 workers (one per CPU) that all compile in parallel. So these typings froze my entire computer everytime I ran Jest. What a nightmare to debug!

You should really document the individual API libraries as the recommended way to consume these APIs. And deprecate/remove the big library.

Navigation Menu

Repository navigation

TypeScript typings cause very high memory usage in tsc #2187

Environment details

Steps to reproduce

Workaround

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

TypeScript typings cause very high memory usage in tsc #2187

Description

Environment details

Steps to reproduce

Workaround

Activity

JustinBeckwith commented on May 27, 2020

yjwong commented on May 27, 2020

JustinBeckwith commented on May 27, 2020

rommguy commented on Sep 28, 2020

bcoe commented on Sep 30, 2020

rommguy commented on Oct 1, 2020

bcoe commented on Oct 1, 2020

rommguy commented on Oct 1, 2020

sgb-io commented on Mar 22, 2021

bcoe commented on Mar 30, 2021

geoguide commented on Feb 6, 2023

matsko commented on Jan 8, 2024

andrewliu-rr commented on Jun 24, 2025

noahnu commented on Jun 25, 2025

karottenreibe commented on Feb 27, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions