Automatic npm publish on commit

[Ranguna]

Clear and concise description of the problem

As a developer using faker I want to get the latest merged changes on npm so that I can get access to the latest changes without local npm linking.

Right now, it seems that tag creation is done manually (maybe?) and there are some changes that are not available on the published npm version.

Suggested solution

We could setup some action to execute on master commits to automatically bump versions and publish to npm.

I've used https://www.npmjs.com/package/semantic-release in the past, config is a bit daunting but the result is pretty great.

Additional branches could be created to generate release candidate/alpha/beta releases as well (but personally, I don't really think this is useful).

Alternative

An alternative would be to keep pushing tags manually but maybe do it at a higher frequency ?

Additional context

No response

[Shinigami92]

I think https://github.com/typescript-eslint/typescript-eslint has something like that.
Definitely not real releases on commits, but something like commit / nightly builds would be cool.

Currently we are awaiting #254 and #257, so a release would make no sense anyways.
We hope that we can do that in a few days.
Sorry that we are kinda blocked so long, we working hard on making the base stable and newly organized. (See name of milestone v6.0.0)

[prisis]

I have a package that is doing auto release its based on semantic-release (https://github.com/anolilab/javascript-style-guide/tree/main/packages/semantic-release-preset), we (maintainer) just need to talk how we will handle it.

And for the first part that we don't release so fast is, because we doing it in our free time, we always open for help and in the end nobody wants to have a broken release ;)

[Ranguna]

Sorry that we are kinda blocked so long, we working hard on making the base stable and newly organized.

Not at all, I'll patiently wait!
Thanks for the awesome work!

And for the first part that we don't release so fast is, because we doing it in our free time

100% completely understandable!

nobody wants to have a broken release ;)

Automated tests are not always the answer, but in this case, I think they'd really help preventing the possibility of a broken releases vs having manual human review of releases (maybe the time is better spent on PR review). But maybe I'm missing an important detail here, since I haven't been involved a lot on the community development of this lib.

Also, not saying that it would be good to have this now. Since there are still things that need to be fleshed out for this initial release, but maybe having this in the future once things are running smooth would be cool.

I might try a PR for this. Albeit you'll need to be patient because my past experience is only with gitlab ci 😋

[Shinigami92]

After yesterdays incident, I would love to have a publish on "create git tag"-event
That would let me sleep for two more hours...

[xDivisionByZerox]

This is blocked by #757. We first need a general auto-publish script before publishing each build version,

[github-actions]

Thank you for your feature proposal.

We marked it as "waiting for user interest" for now to gather some feedback from our community:

• If you would like to see this feature be implemented, please react to the description with an up-vote (:+1:).
• If you have a suggestion or want to point out some special cases that need to be considered, please leave a comment, so we are aware about them.

We would also like to hear about other community members' use cases for the feature to give us a better understanding of their potential implicit or explicit requirements.

We will start the implementation based on:

• the number of votes (:+1:) and comments
• the relevance for the ecosystem
• availability of alternatives and workarounds
• and the complexity of the requested feature

We do this because:

• There are plenty of languages/countries out there and we would like to ensure that every method can cover all or almost all of them.
• Every feature we add to faker has "costs" associated to it:
  • initial costs: design, implementation, reviews, documentation
  • running costs: awareness of the feature itself, more complex module structure, increased bundle size, more work during refactors

---

View more issues which are waiting for user interest