-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Do not include @semantic-release/npm by default #1260
Comments
I think that it would be a huge benefit too. I would propose to refactor the standard installation into a sharable configuration and leave it to the user to install what he needs. (We could alter getting started documentation to install the npm-config together with semantic-release in order to not make it harder for the standard use case -> I would even go as far as removing almost anything that is not really needed for a plain semantic-release installation, e.g. This would further allow a new user to understand how semantic release works, as of now it just magically works out of the box without configuring anything. (That's something my coworkers complained about!) |
I could imagine to have semantic-release as-is, but offer a |
But what would be the difference between I appreciate your effort to not make a breaking change but this will be at the cost of clarity of this project. |
Determine the next version, create and push a Git tag.
Well, half of people complains if it works without config, the other half complains if it requires config. 🤷♂️ Originally semantic-release didn't had plugins and npm and github publish were hardcoded. A large part of the user base started to use it then. They most likely do not have any plugins installed in their |
Thanks for clearing up. 👍
In my mind, the declarative way is more attractive. Everybody can clearly see what's going on, nobody has to search for the default behaviour.
Semantic-Release does have a cli to ease the pain of installing, executing For existing projects we should make a pro-contra table:
Feel free to add more comments, I will update the table.
The update pain could be soothed by adding a
Semantic-Release already supports shareable-configs. The current default could be exported into one, thus minimizing the complexity for existing projects by only having to install one package and adding 4 lines of config. I would be interested in some numbers - how many are using semantic-release in the default config, how many are using a custom one. But they will be hard to get. Maybe someone can analyze the dependent repositories for Furthermore: I think |
I understand the argument and I'm not disagreeing. I'm just saying that as soon as we make such change we'll get 25 identical issues open on this repo saying a version of "I updated without reading the changelog, my npm package is not published anymore, please fix it". Overall I would be in favor of having no plugin by default and allow users to add whatever they need. The changes in the code might be simple to do, however the amount of work in terms of communication, support and issue management is enormous. |
@pvdlg what do you think of the proposal of adding a |
That would create a lot of additional maintenance as we would have to either:
Both solution seems clunky and hard to maintain. |
Would it not make sense instead to release semantic-release/core from this repo instead? And have a new repo, with plugins, to release the "full" version? |
We will revisit this discussion after we ship out the current |
Naming wise I would be happy to contribute an update tool to the CLI for Christmas, or maybe this can also be done by a npm |
@leethree @dominykas Ohh, wait I think I misunderstood. By releasing |
No, why would you do that? There are many good and non-complicated options to manage the two separate packages from the perspective of semantic-release maintainers. |
this would be my assumption too. if the core was extracted, i would think it would make the most sense to deprecate the current package in favor of a shareable-config instead. that would still provide the bundling that exists today, but in a more explicit way. |
one thing that comes to mind if a transition like this is pursued would be the behavior of running |
If The |
the current cli for configuring projects is
this does make sense. i could swear i've seen in handle cases where the command didnt match the package name without the flag, but like i said, i haven't paid close enough attention. |
We're using the semantic-release package in our Azure DevOps pipelines, which due to the dependencies takes ages to load:
The only thing we do with semantic-release is calculate the version number and set it on a pipeline variable using the semantic-release-ado plugin. As far as solutions go, considering all that has been said so far is to introduce an option to the configuration, that allows for the skipping of all default plugins.
Normally I'm against introducing booleans to manage (breaking) changes. But considering what's been said it provides the possibility to have the best of both worlds:
|
That would be a nice option. It`s time-efficient, can be implemented right away and is non-breaking. Also, it leaves open the future implementation. |
The default plugins are defined as a dependency of |
How about indicating them as This would install the packages by default and allow for them to be 'excluded' by running the npm-install command with the |
I am happy to support you now. What has to be done to get this implemented? I would create a shared config |
@pvdlg any updates on this? To implement this issue I would:
|
See #1260 (comment). We won't address that at the moment. It's not blocking nor preventing anything to work, it's just a micro optimization that would avoid copying a few files from the npm cache to the local We'll re-evaluate how we want to handle plugins and shareable config after v16 is released. |
I see. If you remove the I don't know anything about Azure Pipelines tasks, but out of curiosity wouldn't it be better to install semantic-release on execution rather than embedding it?
|
I've hit this issue in my project, which doesn't deploy built packages to any npm registry and so doesn't need It's a problem for me because The effect: npm operations invoked indirectly (eg by scripts called from package.json scripts) pick up v7.11.2 unless you mess with |
Yes, I am experiencing the same issue were using |
We've been using semantic-release for a while now and also put it in build tools for other departments in our company. Our main issue is actually this addressed issue. We use nothing of the @semantic-release/npm package and it adds a massive dependency tree. This results in a lot of questions from the other departments why we add such a heavy dependency tree and why we need it. Both the @semantic-release/core idea as optionalDependencies sound good. A tool which is so flexible with plugins should have a very small core I think. If the maintenance between the core package and "full" package is an issue when developing you could think of changing the repo in a mono repo with both packages (also include maybe the other main plugin packages). |
The @semantic-release/npm dependency is giving us major issues on multiple levels. Getting around this dependency feels more hacky by the day and actually already costs a lot of time researching unexpected behaviors.
We love semantic release for all our package. However, this disabled plugin that gets shipped with breaks all natural logic to work with it |
There're pull requests for this: semantic-release/npm#444 and semantic-release/npm#445 Please also remove GitHub from the dependencies. |
warning semantic-release > @semantic-release/npm > npm > [email protected]: This functionality has been moved to @npmcli/fs. "semantic-release": "19.0.5" |
New feature motivation
@semantic-release/npm
is a huge dependency because it depends onnpm
. It's installed by default withsemantic-release
but a lot of projects are not using it. But becausesemantic-release
is installed locally, all of the following things have to be installed but not used.Here's the dependency tree for it:
New feature description
It will be great if
@semantic-release/npm
can be an optional dependency. For backwards compatibility, it should be possible to create a bare-bone version ofsemantic-release
without all the bloat and let users add plugins they need.A similar request was proposed in #827 but it doesn't seem to be solved.
The text was updated successfully, but these errors were encountered: