If someone is running the tool multiple times repeatedly - probably won't in normal use, but might when first testing things - they might possibly run into the createSession rate limit, which IIRC takes a while to reset. Ideally the app should save the tokens to some JSON file like the mapping, and load them and reuse & refresh them instead of logging in with the password.
save access & refresh tokens and reuse them on next run #8
For system-wide I could see it be in AppData for Windows or equivalent on other platforms and have it scoped to the current handle, so tokens are shared while allowing multiple accounts if needed. Flow for app passwords will be easy. I'll skip talking about OAuth here. For instance-specific could be stored somewhere in node_modules, but it breaks expectation of people being able to use it without a JS project. I'm leaning to the first option.
I'd put it in the same folder in some json file, like the post mapping⦠Since the password that is used to log in to generate access tokens is already in the same folder, I don't feel like it would be a problem to also have the tokens there. Just a question how you organize stuff in which file. (In Minisky I have a YAML file with initially username & password and then the library adds the tokens to the same file. Or it could be saved together with the mapping.)
Definitely not in mappings, I want them to be also importable to your webapp or whatever like what I'm trying rn with getting Leaflet comments on my blog. I don't like it also just being dumped in the project root, cause it's already a lot of files, but it seems like the best option here, unless I modify .env with the token. I'm also bit worried about people accidentally just pushing their tokens somewhere, so it would be the best if it's commonly ignored place. Also for app password now I think it should be local cause you can have multiple app passwords.
Related to the OAuth issue. Storing it is a good idea, but the question is where to store it and should it be system-wide or just instance-specific. Could be easily just stored next to the config, but it's starting to feel bit cluttered and normally user won't need to see or interact with it.