Open HoldYourWaffle opened 9 months ago
Woops, I just found out that this is very similar to #625.
@DimuDesigns What do you think of this design?
I just noticed that the proposed remote remove --delete
would fix/implement/cover/duplicate/supersede #799 and #892.
@elderfd and @fantonangeli, what do you think of this approach?
I just noticed that the proposed
remote remove --delete
would fix/implement/cover/duplicate/supersede #799 and #892.@elderfd and @fantonangeli, what do you think of this approach?
@HoldYourWaffle I'm no longer an active user of clasp, but I agree that #799 could be closed in favour of remote remove --delete
@HoldYourWaffle @elderfd My https://github.com/google/clasp/pull/892 PR was to delete the project remotely but what you want to achieve here is a "git remote" behaviour, so IMO it's a different scope and both features can be useful for other users.
@fantonangeli I think there's a misunderstanding, allow me to clarify:
clasp remote remove
by itself would indeed behave like git remote remove
.clasp remote remove --delete
would delete the associated GAS project as well.@HoldYourWaffle I missed the --delete
option, thanks for clarifying.
In this case if I can share my opinion, as a user, I would expect clasp delete
as the opposite command of clasp create
. Even git remote
has no --delete
command.
Please let me know what you think.
Currently there can be only one "canonical"
scriptId
for a codebase topush
,pull
,version
anddeploy
to. This becomes problematic in non-trivial setups (#921, #987).In preparation for improvements to the multi-developer workflow (#921 (comment)) I propose the introduction of multiple Apps Script targets within a project, analogous to git remotes.
Some of these 'remotes' can be shared and tracked by source control, like a staging or production environment, while others must stay private, such as an individual's testing setup.
Usecases
Prior art
625, which calls them "targets", doesn't propose private remotes and is more similar to git branches than remotes. In my humble opinion a mostly stateless remote-based mechanism would be more straightforward to use.
Configuration
A remote is described by a
scriptId
,projectId
andparentId
. These are currently configured at the root of.clasp.json
.I propose to move these properties to a
remotes
array of the following structure:For backwards compatibility the old 'root keys' can be interpreted as a remote with the configured
defaultRemoteName
(see next section). This behavior could be deprecated and removed in the next major version. Combining the 'root keys' with theremotes
option should throw an error.Private remotes
Currently
.clasp.json
mixes shared "project structure" likerootDir
andfilePushOrder
with possibly private "deployment target" configuration. This means.clasp.json
shouldn't be excluded from source control, but can't be shared either.I propose adding the aforementioned
remotes
option to the private.clasprc.json
as well. Remote names should be unique, a shared and private remote with the same cannot coexist. For simplicity a privateremotes
should be incompatible with the shared 'root keys' configuration.This setup is analogous to
package.json
and.npmrc
, where the first describes (shared) project structure and the latter (mostly) private configuration, including credentials.I'd assume most remotes are intended to be private, so to avoid accidents most of the design is "private by default".
Supporting
.clasprc.json
settingsdefaultRemote
: default remote for various commands, analogous toremote.pushDefault
.defaultRemoteName
: default name for remote created bycreate
,clone
and legacy root keys, analogous toclone.defaultRemoteName
. Default value of "default".New command:
remote
Manually manipulating
.clasp.json
like cavemen isn't a great experience, so I propose to add aclasp remote
command analogous togit remote
.This command should have the following subcommands:
add <name> <scriptId>
list
show <name> [...<option>]
rename <old> <new>
update <name> [...<option> <value>]
remove [...<name>]
A detailed proposal for each of these subcommands can be found here.
Adjustments to existing commands
The following commands get a new positional
[remote]
argument at the start:push
andpull
version
andversions
deploy
,deployments
andundeploy
open
,run
,logs
andapis
This new argument is required, unless:
defaultRemote
is configured..clasp.json
still uses a 'root keys' remote. This should show a deprecation warning.Note that this argument is required even if
remotes
contains just one entry. This avoids accidentally messing with a shared (production) remote if a developer forgets to set up their own private one.Some commands need other and/or extra adjustments, a detailed overview can be found here.
Other considerations
.clasp.json
explicitly only contains public information that should be tracked by version control. I'd propose to rename this file toclasp.json
(with the necessary fallbacks to avoid a breaking change) to signal it's public nature, analogous topackage.json
,tsconfig.json
,vite.config.js
and similar shared configuration files..clasprc.json
are inherited from the home and parent directories. Should the same apply toremotes
,defaultRemote
anddefaultRemoteName
?Update 15-11-23: Abandoned the ability for private remotes to override shared ones with the same name. This could lead to unintuitive behavior, (re)designing the commands in a way that avoids this proved too complicated.