ag_dubs

definitely inspired by goreleaser! it's a great project

we actually agree and are working on this! github releases are just an easy initial target, and makes our tool a drop-in replacement for the kinds of things people are already doing. longer-term we'd like to see something more robust, and cargo-dist is the first cog in that machine.

i have personally packaged and published many rust devtools on npm (cloudflare's wrangler, apollo's rover, wasm-pack) but that was largely because they were targeted at a javascript developer audience.

as a former npm registry engineer i'm curious what you find to be the particular value of publishing to npm? installing node is actually very unpleasant and then getting global installs to work is also... very unpleasant. i think it works well for people already in that ecosystem but i think we can build something better for a more agnostic audience that can give a similar out-of-box exp without requiring a centralized registry. would love to learn more about your perspective!

there's a human readable version, you can read more about it here: https://developer.mozilla.org/en-US/docs/WebAssembly/Underst...

fwiw as a former npm registry engineer i can tell u that "hundreds of download every month" likely is a result of the background bot activity npm gets. but your advice is sound! definitely vet your deps before you use them! and YES! read the source.

a few points!

fwiw, only 2 of those humans work on the CLI, (3 if you count their manager, who spends a lot of time managing). other people work in sales, marketing, engineering on the website, engineering the registry, community + docs, etc.

wombat is not a tool for managing our other commercial services! it's a way to manage our webhooks product, one of many products we have, though very certainly the smallest.

yarn depends on the npm registry, which depends on npm, Inc making money to keep it running.

that registry is a mirror of npm's registry. the mirror contains all package data but does not include any of the permissions or user management, so this tool still depends on npm infra for both that, and as a replication source.

ied didn't work on windows because of the linking strategy. many people who need to use npm use windows.

actualyl at this point, unless there is a legal request or a serious security issue, we don't allow any unpublishes. we encourage transferring the package to the npm user and deprecating it. yay immutable registry!

hi! they are running a mirror of the npm registry which contains all the package data but none of the permissions/user mgmt. this means that they are still dependent on npm infrastructure.

npm, Inc strongly encourages people to build and use mirrors. for example, cloudflare (where the mirror lives, and where seb used to work) has been running https://npmjs.cf/ for a long time.

> a serious thundering herd

hehe yup, def want to avoid that

> Are the costs of npm public? Is it mostly bandwidth costs for transferring the tarballs?

the costs aren't but that's an interesting idea. i'll bring it up with the team.

and as for the origin of the cost, transferring the tarballs is a big part but there are other parts of the infra that are also 'spensive. there are a lot of packages, and a lot of users, and a lot of downloads. we're working on reducing the cost of the registry at the same time as trying to increase revenue- hitting the problem from both sides :)

greenkeeper uses the follower ^__^

we're still playing around with how many hooks to give each account- and we're definitely open to increasing it. this is why we're releasing in beta.

as for it being paid, our registry is super expensive to run, so we're looking for ways to make money to support it. this is one way to encourage people to pay for their accounts. this also keeps our prices super low (we start at 7$ a month).

we do have something called the registry follower (https://github.com/npm/concurrent-couch-follower) that can help you achieve a similar outcome, but hooks provides more specificity around certain events and is also significantly more user friendly

this would primarily be for people who use their own internal packages in developing their own applications, i.e. a single author owns both packages.

that being said, it turns out that the semver handshake the community does works Most of The Time, so if it is a trusted dependency it wouldn't be that dangerous. assuming you also had tests-dependent deploy, the tests would catch the break.

you might also consider the fact that OSX machines are expensive. and the education for learning linux is generally expensive or not accessible. so supporting windows also supports ... poor people, people from different countries that have different economies, etc.

should we not pick up capitalism's slack? capitalism sure isn't going to pick up its own slack, err... systemic method of restricting underprivileged/poor people's access to power.

forcing a single copy of a dep is exactly the opposite of the dependency strategy both the node module loader and npm take. the fact that the node module loader can load more than one version of a module into memory is its strength and npm plays to this, and in doing so avoids "dependency hell". you might checkout this page in the docs that talks more about this: https://docs.npmjs.com/how-npm-works/npm2

as the person who wrote these docs-- if you have questions or things you'd like to see addressed, i'd really love if you filed issues on the repo. https://github.com/npm/docs/issues

hi! i totally know this is a common feel for many npmjs users. this is why i've been running an empathy campaign for Windows, Windows Wednesday, where i do all my work (with/for npm) on windows. it's been good for finding bugs, either technical or UX. i'm working on improving the docs to make them friendlier to all platforms (not just OSX, which is the most common platform at npmjs).

npmjs cares about the enterprise + windows.

hey! do you have a specific problem in mind or is this just a hypothetical musing?

'cause the actual changes that break between npm 1 and 2 are very small. (the changes to npm run, mostly, and the cache.) so it's Very Strange(tm) modules that break, and the new run behavior is much more useful

- npm team member