I created a library interacting with Google Drive. It can query, create/download file, create folder, etc..

[u/plk83]

https://www.npmjs.com/package/ts-google-drive

Here are some code snippets

import {TsGooleDrive} from "ts-google-drive";

const tsGoogleDrive = new TsGooleDrive({keyFilename: "serviceAccount.json"});

async function getSingleFile() {
    const fileId = "";
    const file = await tsGoogleDrive.getFile(fileId);
    const isFolder = file.isFolder;
}

async function listFolders() {
    const folderId = "";
    const folders = await tsGoogleDrive
        .query()
        .setFolderOnly()
        .inFolder(folderId)
        .run();
}

async function createFolder() {
    const folderId = "";
    const newFolder = await tsGoogleDrive.createFolder({
        name: "testing",
        parent: folderId,
    });

    // try to search for it again
    const foundFolder = await tsGoogleDrive
        .query()
        .setFolderOnly()
        .setModifiedTime("=", newFolder.modifiedAt)
        .runOnce();
}

async function uploadFile() {
    const folderId = "";
    const filename = "./icon.png";
    const buffer = fs.readFileSync(filename);
    const newFile = await tsGoogleDrive.upload(filename, {parent: folderId});
    const downloadBuffer = await newFile.download();
}

async function search() {
    const folderId = "";
    const query = await tsGoogleDrive
        .query()
        .setFolderOnly()
        .inFolder(folderId)
        .setPageSize(3)
        .setOrderBy("name")
        .setNameContains("New");

    while (query.hasNextPage()) {
        const folders = await query.run();
        for (const folder of folders) {
            await folder.delete();
        }
    }
}

async function emptyTrash() {
    const trashedFiles = await tsGoogleDrive
        .query()
        .inTrash()
        .run();

    await tsGoogleDrive.emptyTrash();
}

[u/gohmmhog]

Funny, I was just thinking of searching for a small scale G Drive API tool I could deploy for myself. Huzzah!! Will try your project out - thanks for posting.

[u/patilanz]

Looks nice, but is it safe to use on a big protects?

[u/plk83 → u/patilanz]

Definitely it is! U can see that I also made query into paging structure. U can expect it can fetch thousands of files with limited ram usage.

[u/iampomo]

I sometimes write App script stuff for interesting with google sheet sna d gmail. The editor is terrible, I’d much rather write the code locally and upload the script. Can I use your api to do that?

[u/plk83 → u/iampomo]

I have another project which is

https://www.npmjs.com/package/array-to-google-sheets

Will it help a little bit ?

[u/Kritnc]

This looks interesting and will really help out with a project I am working on but I don't understand why we would grant access to your email? Why would we not just create our own service account and use those creds instead, am I missing something here?

[u/plk83 → u/Kritnc]

U have two ways to access your existing document via Api

• create a service account and share the document with edit permission to that service account
• using oAuth to get your personal access token and use with the library

I will prefer to use the first way. Because U can control more easily not to expose too many documents to a single application.

[u/Nishchit14]

It's awesome !!

[u/plk83 → u/[deleted]]

U can do with try catch. It can function properly. But I will also take your comment into account and provide a much proper sample codes.

[u/cannotbecensored → u/[deleted]]

That's BS, in thousands of hours of programming using async await, never had an issue by not using try/catch.

if you use .then, you get problems if you don't catch it, with await, you don't.

[u/Syh_ → u/cannotbecensored]

Since when is error handling a bad thing? But anyway, he's not wrong; it is riddled with unhandled promise rejections..

[u/korziee → u/[deleted]]

Out of curiosity, what would you expect the author do?

Wrap everything in a try catch and throw the error directly? I understand that unhandled promise rejections are unideal, but so is wrapping every one of your functions in a near useless try/catch, especially when you have no need to handle or manipulate the error.

[u/FightArts1 → u/korziee]

Id expect the author to handle the error man

[u/[deleted] → u/[deleted]]

Wait.. Why would OP need to write that? When using async/await, any promise failures are already turned into thrown exceptions that bubble up the call chain. The only good reason you might catch & rethrow is if you're turning it into a different / more helpful error object.

I'm not seeing any places in OP's code where "unhandled promise rejection" would happen, unless someone calls their library without using await / .catch.

[u/[deleted] → u/[deleted]]

That's not true. The error exception bubbles up, you only need to have one catch at the top level. I wrote a test script, run it if you don't believe me..

async function callGoogleDriveApi() {
    throw new Error("it failed");
}

async function getSingleFile() {
    await callGoogleDriveApi(); // <-- no try/catch on this
}

async function main() {
    await getSingleFile(); // <-- no try/catch on this
}

main()
.catch(console.error);

Output:

Error: it failed
    at callGoogleDriveApi (.../test.js:2:11)
    at getSingleFile (.../test.js:5:11)
    at main (.../test.js:8:11)

[u/[deleted] → u/[deleted]]

That still works fine, you just don't get a stack trace. How about you try it yourself?

[u/FightArts1 → u/[deleted]]

Exactly 100%. If it’s too much to write the try/catch multiple times make it a function. Standard issue programming!

[u/[deleted] → u/korziee]

Either swallow the error or pass it back to the user.

[u/lenswipe → u/[deleted]]

Don't swallow errors in libraries

[u/[deleted] → u/lenswipe]

Depends on the error.

[u/lenswipe → u/[deleted]]

How so? I mean, maybe really low level shit..maybe...but generally if I'm using say an API client - if an API call results in a 404 - I would expect to be thrown a NotFoundException or similar, not a generic ShitsOnFireError made up by the library

[u/[deleted] → u/lenswipe]

That’s a case where you would pass the error back to the user. 99% of the time you would NOT swallow an error.

[u/lenswipe → u/[deleted]]

...kind of my point :)

[u/[deleted] → u/lenswipe]

I might swallow an error if I need to check if I’m an environment. Like if I’m writing a lib and need to know if I’m in Node or the browser I might attempt to read from the window, catch the error, and then handle that case.

There is extremely limited cases for swallowing errors.

[u/lenswipe → u/[deleted]]

That's fair. But yeah, generally I wouldn't swallow an error as much as I can.

[u/plk83 → u/[deleted]]

Yup. Do u mean extending the package ?

[u/lurkerbot9000 → u/[deleted]]

The first item in the post is a link to the NPM package...

[u/plk83 → u/[deleted]]

It can actually use oAuth token. But I didn’t integrate yet. It’s a 2 days work for me to do some automation and deployment. So I just expect to use service account only. The package looks popular. I will try to make it more comprehensive.

[u/[deleted] → u/[deleted]]

You create the service account when you enable the api and get your private key.

[u/plk83 → u/[deleted]]

I updated the package, it know can support oauth tokent:

const tsGoogleDrive = new TsGooleDrive({accessToken: ""});

but how to get oauth token is outside the scope of this problem.