When this action runs it modifies the package.json of any node project present. about conventional-pr-action HOT 14 CLOSED

@jeacott1 Set the auto-install option to false.

from conventional-pr-action.

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

from conventional-pr-action.

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

from conventional-pr-action.

@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?

from conventional-pr-action.

@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?

from conventional-pr-action.

@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.

from conventional-pr-action.

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.

from conventional-pr-action.

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?

from conventional-pr-action.

@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.

from conventional-pr-action.

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.

from conventional-pr-action.

@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

from conventional-pr-action.

@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.

from conventional-pr-action.

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

from conventional-pr-action.

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

from conventional-pr-action.