feat: add support to pull templates from private npm repository

[alextrs]

Description
Extend library to support private repository parameters based on @derberg suggestion

Once merged I will push another PR to CLI to support these new parameters

Related issue(s)
Resolves #538, closes PR #673

[github-actions]

Welcome to AsyncAPI. Thanks a lot for creating your first pull request. Please check out our contributors guide useful for opening a pull request.
Keep in mind there are also other channels you can use to interact with AsyncAPI community. For more details check out this issue.

[alextrs]

@derberg did you have a chance to review this one?

[derberg]

@alextrs nice! looks pretty clean, thanks for the contribution.

Some feedback for now:

• will you also contribute it to the CLI? https://github.com/asyncapi/cli
• please update docs as well in this PR. But maybe once we have the final implementation. @Florence-Njeri @pratik2315 What do you think, do we need separate markdown file or rather update one of the existing documents? and which one?
• did you already test it in your workflows? does it work as expected with arborist?
• I think it would be better to have all registry-related options in one option, just like with templateParams argument. So instead of passing options.registry it would be options.registry.registryUrl, so options.registry would be an object of additional options. Wdyt?

[pratik9315]

Since @alextrs has added the functionality to pull templates from private github repositories, I feel it should go in one of the template docs. Here's what I think:

• If we just want to mention that generator has the capacity to fetch templates from private repos then it should go into --> template concepts doc. (Also that doc already has a mention of arboist library in my pr, still in review!)
• One doubt tho. Would pulling templates from private repos require any additional parameters on the generator CLI?
  If yes --> then its better opt for a new document. If im not wrong, we cannot also put it in template-development since its all about template developers doing their customization magic with templates!

What do you think about it @derberg @Florence-Njeri @alextrs

[alextrs]

@derberg @Florence-Njeri @pratik2315 once we merge this PR I will add it to CLI with documentation (it is ready, just need new version of library). It will be something like this

  registry: Flags.string({
    description: 'Npm registry url',
    env: 'AG_REGISTRY',
  }),
  'registry-username': Flags.string({
    description: 'Npm registry username',
    env: 'AG_REGISTRY_USERNAME',
  }),
  'registry-password': Flags.string({
    description: 'Npm registry password (base64 encoded)',
    env: 'AG_REGISTRY_PASSWORD',
  }),
  'registry-token': Flags.string({
    description: 'Npm registry token',
    env: 'AG_REGISTRY_TOKEN',
  }),

I also tested it through locally built CLI and it works.

[derberg]

@alextrs I think you missed some of my questions.

@pratik2315 good cal with template document. We definitely need clarification there. There would also be a need to add dedicated instruction about CLI in usage document.

[alextrs]

@derberg pushed few changes based on your feedback. Added notes to template.md, let me know if more needed.

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
No Duplication information

[derberg]

for better jsdoc experience can you please:

• add above class type definition for the registry option like https://github.com/asyncapi/parser-js/blob/master/lib/parser.js#L46-L53
• If you call this type RegistryOptions then /** @type {Object} Npm registry information. */ will have to be /** @type {RegistryOptions} Npm registry information. */. If I'm not mistaken as a result we will get a nice API docs generated
• I think that once you add typedef as described above, then you can also reuse it in jsdoc for the constructor, so you do not have to repeat all these options and descriptions as they are there now

[derberg]

Suggested change

	if (invalidRegOptions.length) throw new Error(`There invalid parameters were specified to configure private registry: ${invalidRegOptions.join(', ')}`);
	if (invalidRegOptions.length) throw new Error(`These options are not supported by the generator to configure private registry: ${invalidRegOptions.join(', ')}`);

[derberg]

@alextrs do you need some help to complete this one?

[JFCote]

I'm currently blocked from using AsyncAPI Generator because I can't use my own template that is hosted in our private github package. I'm available to help or test this, let me know! @alextrs

[derberg]

@alextrs is not very responsive this year so might be @JFCote that there will need to me a new PR opened. Would you be open to do that?

[github-actions]

This pull request has been automatically marked as stale because it has not had recent activity 😴

It will be closed in 120 days if no further activity occurs. To unstale this pull request, add a comment with detailed explanation.

There can be many reasons why some specific pull request has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.

Let us figure out together how to push this pull request forward. Connect with us through one of many communication channels we established here.

Thank you for your patience ❤️

[JFCote]

Hi @derberg , what exactly do you want me to do, I'm not sure to understand your previous comment :) Thanks!

[derberg]

I'm asking if you can open a separate PR that is a copy of this + includes current feedback for the implementation

[JFCote]

@derberg Why do you want a copy of this PR when we can only reopen it and work directly on it? :)

[derberg]

it is not yet closed. I just think it is easier to start fresh as the creator of PR is no longer responsive

[derberg]

closing in favour of #1061