Split Zowe/imperative framework into modules

[roman-kupriyanov]

Is your feature or enhancement request related to a problem or limitation? Please describe

Since Zowe/imperative consist of multiple pieces and API's, all the extenders always have to include entire package to have access to only one or two pieces of the provided API's. An example we have: our extension requires access to Zowe REST Client API only, but together with it we also include all other API's and, what is most problematic, all their dependencies.

Yes, there are bundlers like webpack or esbuild which potentially "tree shake" all the unnecessary imports, but the main concern here are the dependencies and the dependency checkers like Black Duck are constantly complaining about the dependencies that we most probably not even use.

Describe your enhancement idea

Possibly to split Zowe/imperative into the pieces, thus the extenders may select and add only required API's to their projects (e.g. @zowe/imperative-rest, @zowe/imperative-profiles, @zowe/imperative-cli or similar)

Describe alternatives you've considered

None

Provide any additional context

None

[github-actions]

Thank you for raising this enhancement request.
The community has 90 days to vote on it.
If the enhancement receives at least 5 upvotes, it is added to our development backlog.
If it receives fewer votes, the issue is closed.

[t1m0thyj]

If the main concern is to reduce the number of dependencies pulled in by the Imperative package, perhaps we could expose the non-CLI specific parts of Imperative from the Core SDK which currently has very few dependencies?

It would be easier for us to make this change rather than splitting out Imperative into lots of new SDK packages, while still eliminating most of the dependencies such as cli-table and yargs.

[roman-kupriyanov]

@t1m0thyj,

If the main concern is to reduce the number of dependencies pulled in by the Imperative package, perhaps we could expose the non-CLI specific parts of Imperative from the Core SDK which currently has very few dependencies?

Yes, and that too, but the main idea is to have access to some APIs from the other utilities which are not going to create Zowe CLI plugins exactly, but might be interested in using, to say, the profiles API to be able to read Team Config values and share configurations and settings within the Zowe infrastructure.

I do not know how it may affect Zowe conformance criteria since the only Entire Zowe CLI conformance criteria is available, but maybe those pieces of SDK should not be covered by the conformance program at all.

[oseam87]

This would be great, my vscode extension went from 100KB to 2.3MB because of this, even though I'm using esbuild. Would using webpack make any difference?

This would also benefit the zopeneditor extension, I think.