fix(deps): move patch-package to prod deps for ci

[tim-lai]

Description

• Restore postinstall hook
• move patch-package to production dependency

Motivation and Context

reverts #8287 and supercedes #8266

How Has This Been Tested?

local npm link with SwaggerEditor appears to work.

Screenshots (if appropriate):

Checklist

My PR contains...

• No code changes (src/ is unmodified: changes to documentation, CI, metadata, etc.)
• Dependency changes (any modification to dependencies in package.json)
• Bug fixes (non-breaking change which fixes an issue)
• Improvements (misc. changes to existing features)
• Features (non-breaking change which adds functionality)

My changes...

• are breaking changes to a public API (config options, System API, major UI change, etc).
• are breaking changes to a private API (Redux, component props, utility functions, etc.).
• are breaking changes to a developer API (npm script behavior changes, new dev system dependencies, etc).
• are not breaking changes.

Documentation

• My changes do not require a change to the project documentation.
• My changes require a change to the project documentation.
• If yes to above: I have updated the documentation accordingly.

Automated tests

• My changes can not or do not need to be tested.
• My changes can and should be tested by unit and/or integration tests.
• If yes to above: I have added tests to cover my changes.
• If yes to above: I have taken care to cover edge cases in my tests.
• All new and existing tests passed.

[char0n]

@tim-lai IMHO this is not very optimal solution. This PR introduces patch-package@6.5.0 as a production dependency which introduces 50 new dependencies into our production dependency tree. This dependencies will not be used in production bundles, but will pose additional false positive issues with SCA (Software Composition Analysis) tools or SBOM (Software Bill Of Materials) tools.

Graph generated by https://npm.anvaka.com/#/view/2d/patch-package

I did brief research into how patch-package works. It creates patches with fixed paths

diff --git a/node_modules/tachyons-sass/scss/_clears.scss b/node_modules/tachyons-sass/scss/_clears.scss

--- a/node_modules/tachyons-sass/scss/_clears.scss
+++ b/node_modules/tachyons-sass/scss/_clears.scss

When SwaggerUI get installed in target env as npm package, the paths can easily looks like this:

node_modules/swagger-ui/node_modules/tachyons-sass/scss/_clears.scss

I've created a comment mentioning the author to merge the fix in tachyons upstream project - tachyons-css/tachyons-sass#63 (comment). We can also contact him via twitter or linkedin if he doesn't respond in some reasonable time.

Overall I think this PR is trying to fix downstream issue with hacky non-reliable monkey-patching way. We want to wait until is fix provided upstream in tachyons-css/tachyons-sass#63 or stop using this old library.

Proposal of remediation

We build SwaggerUI CSS with webpack. We can fix the problem directly in our webpack config by utilizing simple text replacer plugin and replacing the *zoom with zoom. This solution is systematic, affects positively all downstream projects and no non-reliable monkey patching happens. It also solves dependency issue I've described in this comment.

Alternative solution is to install https://github.com/shelljs/shx as dev-dep and run shx sed right after the swagger.css is generated to replace the *zoom string.

[tim-lai]

I've created a comment mentioning the author to merge the fix in tachyons upstream project

fyi, there's been various pings to get a new tachyons release out that includes merged PRs that solve other issues. So unfortunately it's not something I think we should count on happening.

[tim-lai]

We can fix the problem directly in our webpack config by utilizing simple text replacer plugin and replacing the *zoom with zoom.

Will look into this, thanks!