Support options to specify dotfiles about clasp HOT 33 CLOSED

Since it's pretty easy just to write a bash command to swap/move .clasp.json files, I'm probably not going to think about this for a bit.

You could just have:

.clasp.prod.json
.clasp.dev.json

And cp which one you need:

cp .clasp.prod.json .clasp.json

from clasp.

@grant
I think that use-cases is the following:

• I want to push to different scriptId. For example, switch environment as development, staging, production. Many users use application on production environment. I want to develop (coding, test, etc) on development environment. I pull source code from development environment and push staging or production environment.
• I use mutilple Google accounts on different domains. I develop a application on one domain and then I deploy the application other domain. I need to use credential for different domain at same time.

from clasp.

OK. There are 2 separate requests, multi-scriptIds & multi-account.
This is complicated, bear with me..

Multiple scriptIds for the same clasp project (ProjectSettings)

Question: Why does someone need to push to multiple parallel Apps Script projects, like dev/prod?

• 1 clasp project can push to multiple scriptIds (dev/staging/prod).
  • Currently all API requests use: .clasp.json (scriptId/rootDir)
  • We need to change the ProjectSettings to enable multiple scriptIds.

// A single script/environment pair
type EnvId = string; // dev/staging/prod
interface Env {
  envName: EnvId;
  scriptId: string;
  rootDir: string;
}

// Project settings file (Saved in .clasp.json)
interface ProjectSettings {
  scriptId: string; // default env
  rootDir: string;  // default env
  envs: Map<EnvId, Env> // custom scriptIds (NEW)
}

Multiple Google accounts (ClaspSettings)

• For multiple Google accounts, we need to support multiple ClaspSettings'.
  • 1 global (default) ~/.clasprc.json for all clasp projects
  • N local .clasprc.json for different Apps Script projects

type SettingsId = string; // global/corp/myProject
// Project settings file (Saved in .clasp.json)
interface ProjectSettings {
  scriptId: string; // default env
  rootDir: string;  // default env
  settingsId: SettingsId; // custom API keys (NEW)
}

// Clasp settings file (Saved in ~/.clasprc.json)
interface ClaspSettings {
  access_token: string;
  refresh_token: string;
  token_type: string;
  expiry_date: string;
  customSettings: Map<SettingsId, ClaspSettings>; // enables custom API keys (NEW)
}

And login to a custom environment:

clasp login # default Google account to use with clasp
clasp login "corp"

An example ~/.clasprc.json could look like this:

{
  "access_token": "asdfqwer",
  "refresh_token": "asdfqwer",
  "token_type": "Bearer",
  "expiry_date": 1519634151379;
  "customSettings": {
    "default": {"access_token": "tok", "refresh_token": "bay", ...}
    "work": {"access_token": "foo", "refresh_token": "bar", ...}
    "personal": {"access_token": "baz", "refresh_token": "bat", ...}
  }
}

• Using your own .clasprc.json access_token will enable you to use the execution API #11 (clasp run foo).

Warnings

• We also need to add better error messages for when a user tries to pull/push from an account they don't have
• We need to signify which environment the user is currently logged into to prevent access denied mistakes.

from clasp.

I'm not hear to start a war or anything, but do realize that not everyone knows how to write bash scripts. CLI arguments are, in my opinion, much more approachable to a wider audience. I also just happen to think that it makes for a cleaner, declarative solution to working with environment-specific configuration needs.

from clasp.

Sorry to not be able to contribute to this project. I moved teams.

@PopGoesTheWza Since you've worked a lot on this project, and nobody else is maintaining this project, I've given you maintenance permissions for this repo. I think that is better than a fork. Feel free to ask others for PR reviews and merge as you see fit.

If you want to publish @google/clasp, I can look into it, but can't do this often.

from clasp.

@khalilchoudhry Please give a try at this forked branch

It includes most of pending PRs: #724 #700 #708 #721 as well as infamous #688 for env variables and config files.

A drafted doc is here under /doc

Download and build with the command:

npm uninstall -g @google/clasp && npm install && npm audit fix && npm run build

The environment variables clasp_config_project, clasp_config_ignore and clasp_config_auth can the be used to reference config files.

`

The clasp --help command should now display new options to reference config files:

$ clasp --help
Usage: clasp <command> [options]

clasp - The Apps Script CLI

Options:
  -A, --auth <file>                           path to an auth file or a folder with a '.clasprc.json' file.
  -I, --ignore <file>                         path to an ignore file or a folder with a '.claspignore' file.
  -P, --project <file>                        path to a project file or to a folder with a '.clasp.json' file.
  -v, --version
  -h, --help                                  output usage information

[...]

Sorry for I had no time to test it.

from clasp.

Try https://www.npmjs.com/package/forked-clasp version 2.7.0

from clasp.

@fossamagna you can use a GAS starter project with a build that will switch those files for you (https://github.com/JeanRemiDelteil/gas-shell)
This project also comes with a number possible configurations to patch the gas manifest file for example.

from clasp.

Other issue is that often bash script differ from OS.
When you work with a team it's difficult to get this working everywhere.

from clasp.

I support this feature, a more detailed potential solution would be nice.

I propose the .clasp.json file should have an env property like npm:

https://docs.npmjs.com/misc/config

A more detailed spec of what this would look like would be important.

PRs are welcome.

from clasp.

@fossamagna / @JeanRemiDelteil Can you please describe what use-case you're thinking of? For instance:

• Do you specifically want to pull and push to different scriptIds within the same folder?
• Do you want to use different access_tokens to push to different logged-in Google accounts?

We should clarify the problem and ideate on potential solutions.

from clasp.

@grant
Thank you.
Now, I open pull request #56. I add cli option to support multiple environment at this PR. But, there is a different specifications of .clasp.json as your proposal . It's [defaut/global] environment handling. The specification of #56 has no compatibity to now version. I intend to alter the #56 in response to your proposal specification.

from clasp.

I have understood that ProjectSettings.settingsId and key of customSettings is related. Then to support multiple account and multiple scriptId, I consider that Env interface should be have settingsId property.

from clasp.

Update:

• Multiple Clasp Settings/Google Accounts will come in clasp@2
  • It is needed for clasp run #11.
• I don't see multi scriptIds per coming in the near future though tbh. PRs are welcome.

from clasp.

While working on #349, I figured I'd look at adding envs to .clasp.json.
I was thinking something like this:

interface ProjectSettings {
  scriptId: string;
  rootDir?: string;
  projectId?: string;
  fileExtension?: string;
  filePushOrder?: string[];
  env?: {
    [name: string]: ProjectSettings,
  };
}

and then merging anything under settings.env[process.env.CLASP_ENV] with the root settings.

This would let you have this in your .clasp.json

{
  "scriptId": "<staging-script>",
  "rootDir": "./",
  "env": {
    "production": {
      "rootDir": "./dist",
      "scriptId": "<production-script>"
    }
}

Is this the route you were thinking? Is having the interface as envs: Map<EnvId, Envs> essential?

from clasp.

This would require changing ~/.clasprc.json (credential storage), .clasp.json (which credential to use), if this would to be implemented.

The design still would need to be figured out.

from clasp.

Does any of the submitted PRs work? I have a similar requirement so I checked most of the PRs related to this task are closed. Would anyone guide me to the correct docs for this?
@fossamagna How did you solve it then?
Thanks.

from clasp.

@khalilchoudhry I have little use of @google/clasp currently. There are many PR pending and little attention from Google since @grant moved to new horizons.

The above PR should work, though it didn't went through much testing.

I would consider hosting and maintaining a fork if enough people are interested.

from clasp.

@PopGoesTheWza I guess 6 people are interested including me and @fossamagna and as you have mentioned other issues in the above PR (PopGoesTheWza:dotfiles-override), that may include a few other interested people. If you could host & maintain, I would be happy to help if required.

from clasp.

I will try to take the tile to review this next week. So much already on my plate.

from clasp.

Thanks. I will clone your fork and try to do a few tests and see how it works and update/consult if something is required. I need to set up the staging branch next week for my project.

from clasp.

@khalilchoudhry give me a few hours and I'll tidy my repo with a clean branch for you (and others?) to get started and test.

from clasp.

@PopGoesTheWza Sure I will give it a try today.

from clasp.

Thanks @grant

from clasp.

Thanks for the discussion - interested in this too!

from clasp.

@PopGoesTheWza is your fork or branch merged?

from clasp.

@khalilchoudhry I happened to delete the fork on my repo... A mix of mistake and bitterness.

Hopefully in a couple of months I am likely to revisit how config files are handled and implement a better cleaner design.

At least with the latest refactoring PR here things are looking better.

There is still the issue of no one from Google G Suite team being available to deal with npm releases though.

from clasp.

ah, I was using it!

I can only wait then I guess.

Thanks!

from clasp.

Sorry for that. If one has still a copy of that branch, I’d gladly restore it

from clasp.

@PopGoesTheWza Hey, any hope? Will it be merged or fixed any time soon?

from clasp.

@khalilchoudhry I'm struggling for some free time to get back on this issue.

from clasp.

Try replacing @google/clasp 2.3.0 with forked-clasp which is more advanced.

npm uninstall -g @google/clasp
npm install -g forked-clasp

from clasp.

Fixed in https://github.com/google/clasp/releases/tag/v2.3.1

from clasp.