I'm the original co-author of the "Conventional Commits" spec. Although, I should give credit where credit is due, and say that it evolves directly from Angular commit conventions.
I started adopting these conventions with the goal of automating releases, both on my open-source and on the services I was working on at npm (I've since brought the practice to my team at Google).
I very much did not want to introduce road blocks to folks committing to their own branches -- which is what the "rewrite the message when you squash" advice grows from.
Here's a post I wrote on how my team uses Conventional Commits in our release process:
man alive, an irresponsible approach to shutting down a SaaS like this is exactly why infrastructure startups face an uphill battle getting folks to adopt them.
> I'm curious what the percentage of npm publishers that have this toggled on is, and I wish that was available data.
I know we're tracking this data and I bet a follow up post will be written at some point once some numbers are available. As you say, I expect 2fa will see wide adoption as soon as a stable version lands in the upstream Node.
We use Atom's syntax highlighter for syntax highlighting on npmjs.com -- I originally wrote onigurumajs, because I was seeing if we could viably remove the website's only compiled dependency (oniguruma) ... I wrote it over vacation, and then had to put the work down.
I would love help to see the library over the finish line; on a grammar by grammar basis it would be great to figure out what the JavaScript regex engine is missing, and try to shim the logic.
why???
The great thing about using oniguruma, is that it lets you leverage the huge collection of grammars available for TextMate -- unfortunately JavaScript's regex engine doesn't support quite a few rules that are present in TextMate grammars.
As one of the folks on the front-lines helping patch this, I certainly have no hard feelings; and I'm excited to be able to support this feature properly
... also ... not going to lie, this was the first time we've gotten to test several of the checks and balances we have in the npm registry which I was jazzed about :)
We've had the opposite experience using Replicated for npm's on-prem npm Enterprise software.
I was originally trying to build our Enterprise solution using Ansible, targeting a few common OSes (Ubuntu, Centos, RHEL); headaches gradually began to pile up, surrounding the "tiny" differences in each of these environments -- I'm VERY happy to offload this work.
It took me a little while to wrap my head around best practices regarding placing our services in Docker containers, but once I was over this conceptual leap I was quite happy.
Similar problems exist in most package management systems. registries that have a manual review process mitigate this danger, but there's still always a risk of malicious code getting into the world.
Having said this, we'd like to make exploits such as those discussed in #319816 as difficult as possible. We're exploring supporting new authentication strategies: such as 2-factor authentication, SAML, and asymmetric key based authentication (some of these features are already available in our Enterprise product, but haven't made it to the public registry yet). npm's official response has more details on this subject:
Even though I try to be diligent about keeping my dependencies up-to-date, they tended to always drift away from truth -- updating is a sometimes frightening chore that's easy to put off.
I'm enabling Greenkeeper.io on all my OSS projects, and it makes this chore much easier.
I believe Alpine is GPL licensed. Curious what companies are using Alpine? What ramifications does this have on the licensing of a micro service running in Alpine.
we're using Replicated to build out our on-premises solution at npm. It's bee a great experience: along with providing a great UI for installing and pushing updates; it's been the impetus we need to push us to play with docker more, I've found that this mindset has helped the overall quality of our SOA.
When packaging up various npm components, BusyBox was recommended to me as a great solution for creating containers with a low overhead -- I eventually stumbled across Alpine (which is built on top of BusyBox) and have been really happy.
Alpine has a tiny footprint, which is great for wrapping Node.js which itself is tiny; But wait, there's more, Alpine has a great package-manager similar to apt, called apk -- this is what sold me on it over BusyBox.
I'm relatively new to Babel + ES2015 myself and would love to hear about how other people structure their projects: do you transpile your ES6 code before running tests on it, what suite of tools do you use for transpiling? What are other caveats folks should keep in mind when using Babel?
I'm the original co-author of the "Conventional Commits" spec. Although, I should give credit where credit is due, and say that it evolves directly from Angular commit conventions.
I started adopting these conventions with the goal of automating releases, both on my open-source and on the services I was working on at npm (I've since brought the practice to my team at Google).
I very much did not want to introduce road blocks to folks committing to their own branches -- which is what the "rewrite the message when you squash" advice grows from.
Here's a post I wrote on how my team uses Conventional Commits in our release process:
https://dev.to/bcoe/how-my-team-releases-libraries-23el