<#488 RFC: Remove CLI &amp; Standalone API (Pact S...
# pact-js-development
g
#488 RFC: Remove CLI &amp; Standalone API (Pact Standalone Tools - Ruby), and migrate into sister package pact-js-cli Issue created by YOU54F Previous issues Relates to this PR which is now closed, but we will look to raise a new one Problem Removing the standalone tools from the pact-js-core project, would reduce our package size by ~250mb, and allow users to add in a companion package pact-js-cli if they wish to utilise the standalone tooling. This will reduce the complexity of the pact-js-core project, and reduce testing times in CI Steps • Publication of sister package pact-js-cli with CLI & Standalone API • Removal of CLI & Standalone API from pact-js-core • Removal of Pact-ruby-standalone from pact-js-core Breaking Changes Does your proposed change include anything which would require a major version bump? If so, please detail them here. Please read the SemVer spec if you are unsure what this means. This PR removes the binstubs, the Ruby binaries, and the API that exposed them. The following classes are removed: • Publisher • Message • Server • AbstractService • Stub • CanDeploy • CannotDeployError • (all associated options types). The following methods have been removed from the default export and `new Pact()`: • createServer • listServer • removeAllServers • createStub • listStub • createMessage • publishPacts The following (all) binstubs have been removed: • pact-broker • pact-message • pact-mock-service • pact-provider-verifier • pact-stub-service • pact • pactflow User Actions Users leveraging the standalone bin stubs, or api, would need to add
@pact-foundation/pact-js-cli
to their package.json and update their imports in code. Users not leveraging the standalone bin stubs, or api, would need to make no changes, and would see no impact bar a smaller package size. Potential Downsides/Caveats A clear and concise description of any downsides or caveats your change would introduce. • not tested this with PactJS to see if there are changes needed there too. I would expect there are. • This PR removes the repository trigger for ruby standalone updates. We should ensure that the repository trigger is connected to the Pact-JS-CLI repo before merging this. • Many users are using this API for pact publishing, and it is re-exported by Pact-JS (or, at least, it used to be). There should be a discussion on whether it is acceptable to remove the programmatic use of Pact before merging. Thoughts from @Timothy Jones
My gut feeling is that users will want to be able to call at least the pact broker programmatically - some users will already have programmatic use baked in to their existing pipelines, as this was the pattern in the examples for a long time. It would be annoying to bring in a breaking change for those users. Removing the programmatic use also means that users can't build cool things on top of pact as easily.
I feel the same, I think it would be quite a breaking flow to users, to remove the API access for users to call it programatically. I was one of those users who had that baked into my pipeline. I would suggest the API layer is moved over to pact-js-cli, to allow for frictionless migration. pact-foundation/pact-js-core