Add secrets-for-zowe-sdk dependency to ZE API

[JillieBeanSim]

Proposed changes

After some testing of importing ZE API as a dependency for extender since the @zowe/secrets-for-zowe-sdk was added and saw issues. This PR adds the dependency to the package and moves the zowe-explorer's to top-level similar to how we handle the @zowe/cli dependency in the monorepo. I also added the check in the ZE API build command script for the package.

Release Notes

Milestone: 2.10.0

Changelog: n/a

Types of changes

What types of changes does your code introduce to Zowe Explorer?
Put an x in the boxes that apply

• Bugfix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Updates to Documentation or Tests (if none of the other choices apply)

Checklist

Put an x in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This checklist will be used as reference for both the contributor and the reviewer

• I have read the CONTRIBUTOR GUIDANCE wiki
• PR title follows Conventional Commits Guidelines
• PR Description is included
• gif or screenshot is included if visual changes are made
• yarn workspace vscode-extension-for-zowe vscode:prepublish has been executed
• All checks have passed (DCO, Jenkins and Code Coverage)
• I have added unit test and it is passing
• I have added integration test and it is passing
• There is coverage for the code that I have added
• I have tested it manually and there are no regressions found
• I have added necessary documentation (if appropriate)
• Any PR dependencies have been merged and published (if appropriate)

Further comments

[codecov]

Codecov Report

Patch coverage: 100.00% and no project coverage change.

Comparison is base (0669b68) 92.62% compared to head (87d4c10) 92.62%.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #2423   +/-   ##
=======================================
  Coverage   92.62%   92.62%           
=======================================
  Files          98       98           
  Lines        9411     9414    +3     
  Branches     1951     1951           
=======================================
+ Hits         8717     8720    +3     
  Misses        693      693           
  Partials        1        1           

Files Changed	Coverage Δ
packages/zowe-explorer-api/src/index.ts	100.00% <100.00%> (ø)

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[rudyflores]

Thanks for this change Billie!

[zFernand0]

LGTM! 😋

TLDR: (if possible) I would like to see the CLI being exported from the ZE API
That's the reason for my requested changes.

We should merge this PR before Rudy's.
Definitely fixes the following issue in Rudy's PR: 😋

[2023/08/21 13:16:28.483] [ERROR] [CredentialManagerFactory.js:151] Error: Failed 
to load Keytar module: Cannot find module '@zowe/secrets-for-zowe-sdk'

---

Also, I didn't know whether this is the right place to ask for this or not... but could we export an instance of zowe from the zowe-explorer-api?
That way, VSCode Extenders don't have to import from node_modules of the ZE API in order to bypass the annoying ProfileInfo error not being from the same location as the ZE API.

---

And there is one more thing to note (for Extenders)...
There are a few methods that could be broken given that the function signature of getProfileFromConfig changed to include the undefined.

• How is that breaking?
  • It's possible for an extenders to have defined something of type IProfAttrs and TypeScript won't let them transpile/compile because it's not the same as the union of IProfAttrs | undefined 😋

---

Last, but certainly not least...
In the event that an extenders has not updated their CLI dependency, we could be breaking them by introducing new optional method to the ZE API...

• How?
  • For instance the dataSetsMatchingPattern has a signature that includes an interface called zowe.IDsmListOptions, which was introduced in @zowe/cli@7.3.0
    • the CICS extension still had 7.2.3 😋

So, you can imagine if an extender has a version of the CLI lower than that, then they may get issues like this:

node_modules/@zowe/zowe-explorer-api/lib/profiles/ZoweExplorerApi.d.ts:297:67 - error 
TS2724: '"/root/gh/zowe/vscode-extension-for-cics/node_modules/@zowe/cli/lib/index"' 
has no exported member named 'IDsmListOptions'. Did you mean 'IUSSListOptions'?

297         dataSetsMatchingPattern?(filter: string[], options?: zowe.IDsmListOptions): 
Promise<zowe.IZosFilesResponse>;

I believe this could be prevented if the ZE API exported their version of @zowe/cli and extenders used that one, instead having another dependency in their package.json files

[traeok]

Just left a quick comment on how the dependencies are structured, but everything LGTM. Thanks @JillieBeanSim

[t1m0thyj]

Also, I didn't know whether this is the right place to ask for this or not... but could we export an instance of zowe from the zowe-explorer-api? That way, VSCode Extenders don't have to import from node_modules of the ZE API in order to bypass the annoying ProfileInfo error not being from the same location as the ZE API.

I like the idea of exporting the Imperative APIs from zowe-explorer-api to avoid errors related to instanceof 👍 Not sure if we want to export the entire CLI package from zowe-explorer-api, because that may prevent us from migrating to the SDK packages in Zowe v3?

Perhaps we could export just the imperative namespace from zowe-explorer-api, and also make the @zowe/cli package a peer dependency of zowe-explorer-api to address the other concerns about optional methods being added.

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication

[zFernand0]

This works perfectly fine for me using CICS.
I tested this PR in combination with Rudy's:

• Provide API for registering callback upon watcher triggered for exten… #2397

LGTM! 😋

[traeok]

Thanks for addressing this @JillieBeanSim!