RFC: Remove CLI & Standalone API (Pact Standalone Tools - Ruby), and migrate into sister package pact-js-cli

[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 @TimothyJones

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.

[YOU54F]

All CLI/API functionality provided by the Pact CLI tools (ruby based) now migrated as of pact-core v15.x to

• Repo

  • https://github.com/pact-foundation/pact-js-cli/

• NPM Package

  • https://www.npmjs.com/package/@pact-foundation/pact-cli

• imports

  • @pact-foundation/pact-core imports will now become @pact-foundation/pact-cli for programatic usage of the CLI tools

• npx usage

  • npx --package=@pact-foundation/[email protected] -c 'pact-broker'