Open Martin-Zeithaml opened 1 year ago
It would be great if you could show us how devcheck works, and also give us a list of what package.json files are causing trouble.
I saw some package.json and package-lock files in the production builds. I'm not sure if they are there on purpose ot make blackduck scanning easier, or if they should be removed.
Example of manual process:
/Git/explorer-jes$ git clone git@github.com:zowe/explorer-jes.git
/Git/explorer-jes$ cd ./explorer-jes
/Git/explorer-jes$ depcheck
Unused dependencies
* react-tooltip
Delete "react-tooltip": "4.2.21",
from package.json
/Git/explorer-jes$ npm install
/Git/explorer-jes$ npm run start
Currently the BlackDuck is checking the react-tooltip
and the dependecy uuid
:
BlackDuck_Zowe_zOS_PAX/zowe-2.7.0/explorer-jes/web/explorer-jes/2.0.6 npm/bom
@material-ui/core/4.11.4
@material-ui/icons/4.11.2
babel-polyfill/6.26.0
classnames/2.3.1
immutable/3.8.2
orion-editor-component/0.0.14
prop-types/15.7.2
query-string/6.14.1
react-contextmenu/2.14.0
react-dom/16.14.0
react-redux/5.1.2
react-router-dom/5.2.0
react-router/5.2.0
react-tooltip/4.2.21
+-- uuid/7.0.3
...
Unused packages should not be there at all.
Generally there are packages with many dependencies and every package might cause some BlackDuck warning and in case of unused packaged false warning.
It would be nice to have a tool/process/automation to eliminate unused packages for every ZLUX/webUI repo.
The depcheck
is just an example, it could be probably done by many ways.
Is your feature or enhancement request related to a problem or limitation? Please describe
There are unused or misplaced packages in
/zowe/*/package.json
. These packages are sometimes causing troubles, when additional tool like BlackDuck is used. Usually the version of unused package is not updated, which is very often marked by BlackDuck as old package.Describe your enhancement idea
Automate
package.json
verification:dependencies
with some tool likedepcheck
and include this check topreCommit
or any other appropriate scriptZLUX
reposdevDependencies
tooOr move this automation (if possible) to higher level (some workflow?)
Provide any additional context
Zowe will be better tool. :+1: