Vscode-extension-for-zowe: Create Zowe Explorer API as separate NPM package.

[Colin-Stone]

To enable extenders to have the exact API's specific to Zowe Explorer available at compile time we should publish the API separately from Zowe Explorer as an npm package that will be a dev dependency of both the extender package and Zowe Explorer.

Put simply ZoweExplorerApiRegister which contains the alternative primary profile methods and ZoweExplorerExtender generic methods to be moved into a new npm package.

[travatine]

Hi,
It'd make developing really easy if the NPM package could be published to https://npmjs.org ( the public npm repository).

Thanks

[Colin-Stone]

Hi,
It'd make developing really easy if the NPM package could be published to https://npmjs.org ( the public npm repository).

Thanks

Exactly.

[travatine]

I wonder if this could allow a "Zowe CLI" plugin to easily support either "ZOSMF" or "RSE" connections more easily

[zFernand0]

I wonder if this could allow a "Zowe CLI" plugin to easily support either "ZOSMF" or "RSE" connections more easily

It may help, however there may be more work involved if the desire is to decouple/detach the Zowe CLI from ZOSMF

[phaumer]

I think this would be great for extenders and for us to govern API changes.

We could turn our current git repo into a monorepo that contains explorer, api, and even perhaps the ftp extension that I am trying to donate as separate package. Similar to how the Theia team organizes their components we could build the whole thing with https://lerna.js.org

The code layout would be then more like

\--packages
     |--- api
             |-- package.json
             |-- src
             |-- ..
     |--- explorer
             |-- package.json
             |-- src
             |-- ..
     |+-- ftp
\-- package.json
\-- lerna.json

Building this would create the npm package for the api, and the two vsix files.

[zFernand0]

Topics (in this issue):

1. Separate NPM package for the API Register and other interface definitions.
2. Zowe CLI supporting other types of connections in core API/SDK (e.g. RSE, FTP)
3. Going Monorepo with the Zowe Explorer, NPM pakcage, and FTP Extension.

[zFernand0]

About number #1, I fully support splitting the API Register functions as well as some interfaces we have already defined in the Zowe Explorer out to a separate repo and published into public NPM. Then importing these as dependencies of the Zowe Explorer as well as other Extensions currently dependent on the Zowe Explorer.

About number #2, even though it's technically possible, there are a few other barriers we may need to overcome if we want the Zowe CLI to be able to support IBM RSE in its native APIs.

About number #3, I'd like others to comment since I've already made a few comments on previous occasion or email threads 😋
TL;DR: about my comments related #3: Even though it is possible and has worked for other projects, I see too many challenges that we (as the community) will need to overcome and extra cycles that we need to spend in order to go monorepo (if that ends up being the final decision) that could be better utilized in adding more functionality for our users.

[zFernand0]

TL;DR: about my comments related #3: Even though it is possible and has worked for other projects, I see too many challenges that we (as the community) will need to overcome

Hi again.
About #3: Mono-repo
Even though there may be challenges, I can see the benefits in keeping the NPM package in this repo and publishing it as a separate package. (maybe not the FTP extension though) 😋
Thanks @Alexandru-Dumitru @Pranay154 @lauren-li @phaumer for joining in the discussion!

[VitGottwald]

If I can quickly summarise the pros and cons:

1. Separate repositories:
   
   
   
   • Pros: the git, pipeline and publish setup is the same as with every other repository and is familiar to everyone
   
   
   • Cons: developing, testing and publishing all packages and making sure they work with each other is challenging. Changes in one repository may require changes in other repositories. But having the visibility across multiple repositories is not easy. It requires manual checkout of correct branches/tags of all the repositories. It is easy to make a mistake. Also if a person develops only within the context of one of the repositories it is quite likely that they will not see the impact of their changes to other packages. To avoid this an extra repository for _integration_ is required. This can be used to test all packages together and help to avoid publishing incompatible code. But who will fixe the errors discovered during the integration repository build? The _incompatible changes_ in various packages have been merged and published by now. Which package should address those issues?
   
   
2. Monorepo
   
   
   
   • Pros: Everything is versioned by the (single) repository. A particular commit (branch or tag) paints the full picture of code for all packages. Changes in the code for one package immediately propagate and show if they break other packages and/or require changes there. It is the responsibility of the person making the changes to make sure all packages work together.
   
   
   • Cons: An investment has to be made into proper tooling and the team has to learn new concepts. The most challenging part in my opinion is having an efficient build and pipeline. Because our projects are in TypeScript, yarn workspaces are the natural first step. At the moment npm does not support worspaces, but it is on their roadmap.
   
   

[ghost]

• Cons: An investment has to be made into proper tooling and the team has to learn new concepts. The most challenging part in my opinion is having an efficient build and pipeline. Because our projects are in TypeScript, yarn workspaces are the natural first step. At the moment npm does not support worspaces, but it is on their roadmap.

Curious if Lerna has been investigated? Don't have experience with it, but seems like another popular option for managing monorepos (23k stars on GitHub).

[VitGottwald]

Lerna can actually use yarn workspaces under the hood. So we can adopt it when we feel the need. But I think for our purposes lerna is an overkill.

[phaumer]

Assuming we want to stick with npm, I see that learn can take care of important tasks such as keeping shared dependencies on the top-level node_modules only one, keeping versions in-sync etc.

[phaumer]

One reason why I think we should try sticking with npm is that the vast majority of developers do not have to learn yarn as a new tool. Only the few people who maintain the overall repo need to learn lerna.