GitHub
02/23/2024, 1:24 PM@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