Open stalniy opened 4 years ago
From the source code, it looks like this is the line that needs to be configured
@stalniy, this seems like a pretty easy feature to implement. A configuration key, packageManager
could be added that defaults to npm but could be optionally set to pnpm. Any reason you haven't created a PR yet? Happy to help.
I haven't created PR yet because there was no approval from core contributors of this repo. Usually, things don't get merged without previous discussion :)
Bummer! Thanks for letting me know.
because there was no approval from core contributors of this repo
@stalniy we do appreciate the consideration for that. We do prefer having some agreement before you invest effort into a PR
Apologies for the delayed response. Our maintainers team had been very busy, so some issues like this one have not gotten attention.
It sounds like this is only a need for projects structured as monorepos, is that correct @stalniy @bestickley? semantic-release does not provide official support for monorepos at this time and it is unlikely that we will be able to provide official support any time soon. The most likely improvement we might provide is to improve support for tools built on top of semantic-release. Could you describe your use case so we can consider it if we do invest in that at some point?
@travi, yes that is my use. I would like to run semantic-release recursively throughout my monorepo with pnpm. Totally understand supporting monorepos adds complication to maintaining. From first glance this feature seems simple to me, but I totally respect your decision as you have a broader perspective. Appreciate your work on this awesome project!
keep in mind that there is the option of creating a pnpm plugin yourself to overcome this limitation of the official npm plugin. similar was suggested for this request for yarn support, which is very similar to this request.
would be awesome to have an extension point in the context of this package instead of making a completely new one that copies everything except of few lines
Just ran in to this. would be great to have fixed.
I support having this feature implemented. Currently, I always run into NPM errors because of the dependencies installed by PNPM
After struggling to get this to work I ended up just removing @semantic-release/npm
and running pnpm -r publish
after multi-semantic-release had run, seems to hold up okay although I am sure there will be caveats to this approach.
PNPM is well established and should therefore definitely be supported
After struggling to get this to work I ended up just removing
@semantic-release/npm
and runningpnpm -r publish
after multi-semantic-release had run, seems to hold up okay although I am sure there will be caveats to this approach.
I did something similar for NuGet. The caveat is: Semantic-Release exits with code 0 if no release is necessary. However, Semantic Release still ran the dotnet pack
command (configured via semantic-release/exec's prepareCmd). This produced a package with an existing release's version, so dotnet nuget push *.nupkg
will exit with an error.
I have a feeling PNPM would experience a similar issue.
Hey :), if you still looking for a pnpm solution check https://github.com/anolilab/semantic-release/blob/main/packages/semantic-release-pnpm/README.md
another option for those here looking:
[
'@semantic-release/exec',
{
prepareCmd: 'pnpm version ${nextRelease.version} --git-tag-version=false',
publishCmd: 'pnpm publish --no-git-checks',
},
],
The issue
I use pnpm for monorepo management and semantic-release for publishing new releases. pnpm supports
workspace:
protocol in package.json, so the packages in monorepo can be always linked to local versions, duringpublish
phase thiswoskpace:
protocol is removed.The issue is that semantic release uses
npm
cli tool for publishing which does not removeworkspace:
protocol and eventually the package is published withworkspace:
dependency which cannot be resolvedDesired behavior
Allow to specify either the string template for publishing package or function in plugin options
Workaround
In linux, I can use aliases and alias
npm
topnpm