When this action runs it modifies the package.json of any node project present.

[jeacott1]

if I create an action and checkout a node/react/whatever project with a package.json file, when this conventional-pr-action is run the package.json is modified, adding:

  "dependencies": {
  ...
    "conventional-changelog-beemo": "^3.0.1",

this is clearly undesirable.

[milesj]

@jeacott1 Set the auto-install option to false.

[jeacott1]

@milesj with auto-install false the action doesn't work. Error: Preset "conventional-changelog-beemo" does not exist.

[milesj]

@jeacott1 Yes, a preset is required and that's why auto-install installs it. Either auto-install, install it manually, or change your preset.

[jeacott1]

@milesj I dont see any docs on how that should be done, nor how I would expect to do that without affecting my target project? what's the point of a build validation tool that pollutes the build?

[milesj]

@jeacott1 Conventional commits requires a preset, which is an npm package. It needs to be installed somehow.

This action auto-installs it to simply the process. Typically the action is ran in isolation (as seen here: https://github.com/beemojs/beemo/blob/master/.github/workflows/pr.yml#L5) which is a non-issue. I'm curious why you think this is undesirable since it happens in CI and is not committed?

[jeacott1]

@milesj I'm using this on a react project that has its own package.json. on PR first the PR is vetted by this action for conventional commits - which modifies MY PROJECTs package.json. I then build my project, run tests, and push snapshot artifacts. the fact that this project alters the dependency list of my project is is clearly a problem - it could affect/break things, add libs and transient dependencies.

for releases it isnt an issue because I dont invoke this action.

perhaps if there was an option, or it defaulted to running in a different working directory it would fix the issue? or perhaps better, containerise a version so that it's faster to start and wont try to modify things on the host.

[milesj]

Well there is an option to disable it:

- uses: beemojs/conventional-pr-action@v2
  with:
    auto-install: false

I've also updated the readme with some instructions on these approaches.

[jeacott1]

why dont you just checkout this action to a different directory? wouldnt that fix this issue?

'If you don't want to use automatic installation, you'll need to disable the auto-install option, and add your chosen preset manually to devDependencies in the root package.json."

isnt the root package json here going to be the working tree of the target projects checkout still? manual or auto - how does this help?

[milesj]

@jeacott1 This action is built on JS, and requires the preset to somehow exist. If you weren't using this action, you would have to install all of these deps in your root package.json anyways.

isnt the root package json here going to be the working tree of the target projects checkout still? manual or auto - how does this help?

I hope you understand that the manual approach requires your committing the package.json changes, and not to install the dep as part of the action workflow in CI.

why dont you just checkout this action to a different directory? wouldnt that fix this issue?

I'm not sure what action limitations are, but probably. I would have to ensure it's a clean directory, and then create a random package.json to handle the installation. I don't have time right now to look into this.

[jeacott1]

why would I commit "conventional-changelog-beemo": "^3.0.1" as a dependency of my project - it just isnt.

I'll just find a different action I think. thanks.

[milesj]

@jeacott1 That's how the npm conventional commits packages work.

https://www.npmjs.com/package/conventional-commits-parser https://www.npmjs.com/package/conventional-changelog-preset-loader

[jeacott1]

@milesj sure - so when you setup your action - do it in a different folder and run it from there. (ie use a different working dir). then your npm install will install to your project, and my project will remain untouched.

[milesj]

I don't disagree, just letting you know how it currently works.

[jeacott1]

@milesj sure - I guess the only workaround then is to run it as a separate job as a pre-workflow.