FIX: @W-19649732@: Add in @types/semver as prod dependency to fix client build issues #351
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Background: internal developer found and issue depending on our engines:

Note that without this PR, some clients (unless they pull in @types/semver some other way) were unable to build their typescript code fully when that code depends on our PMD/Flow engines. This is because because our
./packages/*/dist/**/*.d.tsfiles that that we produce contain import statements to semver but semver doesn't bundle its own types.While I was doing this I used
./packages/*/dist/**/*.d.tsto find all imports in our types files and found the following that needed attention:"node:worker_threads" from code-analyzer-eslint-engine (already has @types/node in dependencies)
"semver" from code-analyzer-flow-engine (needs @types/semver)
"semver" from code-analyzer-pmd-engine (needs @types/semver)
"retire/lib/types" from code-analyzer-retirejs-engine (already has retirejs engine)
"node-stream-zip" from code-analyzer-retirejs-engine (already has node-stream-zip)
And it showed that only semver wasn't pulling in its own types.