Publish access to scoped packages are to strict

[zerocity]

Hi,

the permission for @scope packages are to strict setup.
We are using in our setup a mono repo. (gitlab: groupName/projectNameMonoRepo).

We would like to name the @scope how our project name is called.

...
    '@projectNameMonoRepo/*':
    access: $authenticated
    publish: $authenticated 
    gitlab: true
...

I did a small POC for explanation --> https://github.com/25th-floor/verdaccio-gitlab/blob/v2.3.0/src/gitlab.js#L190
for the discussion.

[adepretis]

ping @bufferoverflow - any comments on this? ;-)

[bufferoverflow]

I guess we have no test case for definition of '@projectNameMonoRepo/* within config. Does it work without that definition in a similar way as described within readme ?

[dlouzan]

I'm not sure I understand: you want to have a subproject in gitlab named projectNameMonoRepo sitting under groupName, but you'd like that this subproject name is mapped in verdaccio-gitlab to an npm scope @projectNameMonoRepo? what's the /* in the sample for? internal components of the mono-repo?

[zerocity]

Yes,

like
@projectNameMonoRepo/legacy-clients
@projectNameMonoRepo/components
@projectNameMonoRepo/shared-lib
etc...

With the current setup i would be forced to create new git repos for each npm package.

@groupName/legacy-clients
@groupName/components
@groupName/shared-lib

sorry for the delayed response.

[dlouzan]

Well, off the top of my head I'm wondering how to map the same project name existing in gitlab in two groups (e.g.group1/monoRepo and group2/monoRepo) to a single scope in verdaccio. Which scope should be adressed when asking for @monoRepo/component1?

Maybe I'm missing the point, but this looks to me as a quite particular use case, not easily generalizable between gitlab and verdaccio :-?

[simonbuchan]

Doesn't seem too tricky design-wise:

packages:
  # Set that an admin can publish anything
  '**':
    ...
    gitlab:
      admin: true
  # @mycompany-foo/bar can be published by maintainers in the group foo
  '@mycompany-*/*':
    ...
    gitlab:
      level: $maintainer
      group: $1
  # @mycompany/myproject-foo` can be published by developers in the project foo-repo in group mygroup
  '@mycompany/myproject-*':
    ...
    gitlab:
      level: $developer
      group: mygroup
      project: $1-repo
  # foo-bar can be published by any member of foo-common/bar or foo-server/bar etc...
  '*-*':
    ...
    gitlab:
      group: $1-*
      project: $2
  # @foo/bar can be published to by gitlab user foo
  '@*/*':
    ...
    gitlab:
      user: $1

That is, the packages.*.gitlab key (or maybe packages.*.gitlab.publish?) can take an object, or array of such objects, with properties:

• level: the membership level required
• group: a string pattern for what the group must be, that can contain:
  • literal text
  • $1, $2, etc., that is replaced with the match for the first, second, etc. * / ** in the package glob
  • * / ** matching anything like in the package glob
  • other variables e.g. $user etc... as requested
• project: same, but for the project
• user: same, but for gitlab user id.

That would make the default behavior replicable with:

packages:
  '*':
    ...
    gitlab:
      - user: $1
      - group: $1
  '@*/*':
    ...
    gitlab:
      - group: $1
        project: $2

Of course, that doesn't seem that trivial to implement, and the intersection with how you might want to configure packages sources, etc. might be a pain, but it seems like a decent strawman to start from?

[bufferoverflow]

group and user settings are ignored, this is handled within gitlab and stated as a goal over here.

[simonbuchan]

group and user settings are ignored, this is handled within gitlab and stated as a goal over here.

I'm afraid if this was a response to me, that I don't really understand it. Does it help if I clarify the above is only referring to gitlab's username, user admin state, project name, and project group name? I thought that would be implied by the fact that you're an auth provider here.

Since this is basically declaring a mapping between the group and project path and the package name, based on the rights you have to a gitlab group or project, then I don't see how it conflicts with the goal of "access & publish packages depending on user rights in gitlab", even if it's overly complex for the goal: I was pretty serious about it only being a strawman, and other suggestions for simplifying it are welcome.

For example, perhaps this would work better for you, instead:

auth:
  gitlab:
    package_mappings:
      - '$user'
      - '@$group/$project'
      - '@mycompany-*/$project'
      - ...

i.e. a list of ways to map package names to required project/group membership.

[bufferoverflow]

@simonbuchan We can consider this if you provide an MR, at the moment it is as it is.