BenjaminCoe

Hey,

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

details nearly a year of open-source work that went into bringing V8's built-in JavaScript code coverage to Node.js.

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.

worth mentioning, since this article npm has released two-factor authentication \o/

http://blog.npmjs.org/post/166039777883/protect-your-npm-acc...

make sure you turn it on.

perhaps not as necessary now that SoundCloud managed to close a round, but wrote this little tool last night to backup my SoundCloud data.

Free soloing is actually a bit slower than the fastest free-climbers, which I found interesting: http://adventureblog.nationalgeographic.com/2012/06/25/alex-...

The time spent being especially careful that you don't fall, adds a bit more time than racing up with ropes.

Fun fact, Alex Honnold holds the speed record on El Cap.

I've been summoned :p

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.

I built this library to track signups for an application that has a fairly low request rate.

if you need a higher request rate 🤷 ¯\_(ツ)_/¯ pitch in and help add support for a wider variety of cloud providers.

it's a goal to use the advertised IP blocks of cloud providers where possible, with whois simply as a fallback.

Will happily accept patches for other providers.

AWS (http://docs.aws.amazon.com/general/latest/gr/aws-ip-ranges.h...), GCE (https://cloud.google.com/compute/docs/faq#where_can_i_find_s...), and other clouds maintain an up-to-date list of the ip blocks within their data-centers -- providing for more accurate data than a whois lookup.

however! I just added whois as a fallback, this seems like a really good idea:

https://github.com/bcoe/which-cloud/pull/10

I wrote the npm/npm Enterprise integration for pipelines:

http://blog.npmjs.org/post/144855273708/announcing-npm-for-a...

I was really impressed; It's really slick having the source-control/collaboration and CI/CD so tightly integrated.

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:

http://blog.npmjs.org/post/141702881055/package-install-scri...

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?

Agreed, yargs (the CLI app that this was built for) has very basic requirements -- there are only a few dozen strings in the entire codebase.

Having said this I did make an effort to learn from prior work in the area, basing the library on: https://github.com/mashpie/i18n-node

A friend of mine who did a thorough literature review at PayPal also advocated formatjs.io -- although I think this is a little bit too much power for little old yargs.

My coworker Isaac and I have been hacking on this nifty little tool for a few weeks now.

The main problem that we had to overcome was that test frameworks like node-tap (https://github.com/isaacs/node-tap) spawn many subprocesses.

nyc overrides child_process.spawn, collects coverage reports for all child processes, and pulls a coverage report back together again.

I love the Node/npm community, and have been programming JavaScript for so many years it's hard habit to kick :) I'd love to try my hand at Go though... I think it's awesome to see what practices can be shared between communities.

One approach I've been playing with in JavaScript-land is using Promises for all return values, this means that you consistently know how to interact with a return value, whether its concrete-value is available immediately or at a later time -- this doesn't really solve the problem of consuming other people's libraries however!

I'd love to post a Go-best-practices article on Polyglot Weekly, as a rebuttal. If you or anyone else reading this thread would be interested :)

Having next to no Go experience, and zero Rust experience, I found this article a really fun read. Coming from a Node.js background, it was neat to see the concurrency approaches used in both languages compared -- quite different from a single-event-loop :)

we've made an attempt to make sure that scoped modules are supported in the npm-registry-couchapp:

https://www.npmjs.com/package/npm-registry-couchapp

npm's open-source project which lets you run your own registry on CouchDB.

My main use-case is programmatically throttling the outbound concurrent connections to a VPN. Writing a small proxy server in Node.js seemed like a reasonable approach for this.

At work we've been running into problems performing npm installs over a VPN. I'm suspicious that it relates to executing too many concurrent HTTP requests. This motivated me to create crapify, a tool which lets us experiment with throttling connection speed and concurrency.

I didn't want to check-in the wavs (because they're huge). But, if you run `unitgen mixer --track1=foo.wav --track2=foo2.wav` and pass in two 44100 wavs, you can use `a` and `s` to play with the cross-fade.

I'd love to hack on this with you. My goal is to build out a semi-functional mixer that I could use rather than Ableton, similar problem :)