environment vars & cli options to specify dotfiles

[PopGoesTheWza]

In a fashion similar to tsc --project and tslint --project which allow to specify which (and where) your project configuration file to be used, it would be nice (and useful) to be able to define on the command line different clasp configuration.

Expected Behavior

clasp push --project dev.json
clasp push --project prod.json

Actual Behavior

(some kludgy workaround with additional folders and intricate path references)

Steps to Reproduce the Problem

Specifications

• Node version (node -v): 10
• Version (clasp -v): latest
• OS (Mac/Linux/Windows): Mac (latest)

[grant]

Why can't we:

clasp setting scriptId id1;
clasp push;
clasp setting scriptId id2;
clasp push;

?

What would dev.json include?

[PopGoesTheWza]

@grant I have started implementing the following design:

• overide path and name for .clasp.json, .claspignore, .clasprc.json & appsscript.json by precedence:
  1. commander options (-P, --project, -I, --ignore, -A, --auth -M, --manifest`)
  2. environment variables (clasp_config_project, clasp_config_ignore, clasp_config_auth & clasp_config_manifest)
  3. current implementation

Handling scriptIds directly on the command line is clumsy IMHO. And about half a dozen issues are likely to be addressed with cli option/environment vars overrides.

I am also considering an "extended" .clasp.json interface which would allow to hold it all in one file. I haven't yet fully thought it over, but it could look something like the following:

{
  // "legacy" properties
  "scriptId": "scriptId",
  "rootDir": "rootDir",
  "projectId": "projectId",
  "fileExtension": "fileExtension",
  "filePushOrder": "filePushOrder",
  // "extended properties
  "env": {
    // same "legacy" properties
    "claspIgnore": "pathAndNameToClaspIgnore",
    "clasprc": "pathAndNameToClaspRc",
    "manifest": "pathAndNameToAppsScriptJson",
  }
}

There you could do commands like clasp <cmd> --env <env>

[PopGoesTheWza]

@grant

The goal of this feature request is to enable the user in specifying which/where the following configuration files to be used by Clasp:

• .clasp.json
• .claspignore
• .clasprc.json (local auth)

This sould be possible through:

• environment variables:
  • clasp_config_project
  • clasp_config_ignore
  • clasp_config_auth
• cli options:
  • -P, --project <file>
  • -I, --ignore <file>
  • -A, --auth <file>

The rules to resolve a config file path would be by priority order:

1. if defined via cli option, use this value
2. if defined via environment variable, use this value
3. use default/current behaviour

values can be absolute and relative path to a directory containing a config file of the default name (i.e. --project env/dev where a .clasp.json exist), or a path to a dotfile (i.e. --auth .clasprc_test.json)

[PopGoesTheWza]

@grant comments? thoughts?

[grant]

I can’t really support feature that don’t have at least 10 users or solves a key use case.

I would maybe fork clasp if you really can’t use bash commands to do this and want to add it to the CLI.

[PopGoesTheWza]

I can use command line or use my own fork even. The proposed change would potentially address #12 #483 #524 #12 #42 I think, but at that point I’ll Wait for more traction/support.

[chechedotmx]

I want to "git" my gas project, but I need to add some hardcode id´s (google sheet) to the git repository, it would be great to have environment variables inside .clasp.json to avoid the versioning of this id´s

[grant]

A design/PR that only included the following would be fine:

• CLASP_PROJECT
• CLASP_AUTH

no flags, ignore file would be in the project. Be sure to document the variables.

[PopGoesTheWza]

@chechedotmx would environment variables to specify .clasp.json & .clasprc.json address your need?

[PopGoesTheWza]

@grant why no flags (cli options)? You're spoiling all the fun!

[grant]

Want to start simple. Also flags may conflict with existing command flags.

[PopGoesTheWza]

@grant I already did the full PR, so limiting to only .clasp.json and .clasprc.json should not be problem. Even dishing out the cli options (which do not conflict)
I only need @chechedotmx approval to start.

[chechedotmx]

Sounds good @PopGoesTheWza