yarn

Created an issue over at the Yarn repository: https://github.com/yarnpkg/yarn/issues/6538

Hello! Link: https://github.com/ramasilveyra/gitpkg A year ago I've published a tiny concept (or hack) to be able to have a private registry on a git repo that: - Works with projects with build steps. - Works with projects with multiple packages (monorepos). - Creates lightweight git tags (only the files needed are included). Some people told me that this can be a good idea and are eager to help me to build more stuff around this, like a tool to create a website from the gitpkg registry. What do you think? Should I give more time to develop this idea and build a more usable PoC? Example of issue that this concept could solve: https://github.com/yarnpkg/yarn/issues/4725 Thanks!

We'll see what the community response is, and once we're confident this is what everyone wants we'll merge it into master (PR is already up[1]). While there isn't an official build at the moment, the code PR includes a prebuilt version of the current branch, and we have a playground repository to experiment with it. [1] https://github.com/yarnpkg/yarn/pull/6382 [2] https://github.com/yarnpkg/pnp-sample-app

Here's an issue I've experienced with using upgrade: https://github.com/yarnpkg/yarn/issues/5749

Contrast this to Yarn’s response, also this holiday weekend, to an outage incidentally caused by the NPM team. https://github.com/yarnpkg/yarn/issues/5885#issuecomment-392... Professional, responsive, not afraid of blowback from accepting feedback and “+1” posts. Is there any reason to lock the post besides bruised ego and overwhelming phone notifications? Neither of those is justifiable when you’re emitting teapot errors because you implemented a spec wrong. This feels very indicative of a toxic, amateur culture, and perhaps we’ve let it operate our package infrastructure for too long.

Based on the (recent) comment on the issue [0], they use the Cloudflare proxy instead of an actual CNAME /and use workers to do yarn-specific changes on the edge / (see below). [0]: https://github.com/yarnpkg/yarn/issues/5885#issuecomment-392...

"We (aka npm) are in contact with Cloudflare to get this third-party CNAME allowed. I'll update this thread when I hear back." (via [0]) More status on the Github issue [0] than yarn status page [1] [0]: https://github.com/yarnpkg/yarn/issues/5885#issuecomment-392... [1]: https://status.yarnpkg.com/

Issue is here: https://github.com/yarnpkg/yarn/issues/5885 The problem is that npm just migrated their registry to use CloudFlare. Yarn already used CloudFlare, and had https://registry.yarnpkg.com CNAME'd to https://registry.npmjs.org. CloudFlare has a security restriction that one CloudFlare account cannot have DNS records pointing to another CloudFlare account, so npm moving to CloudFlare broke yarn's existing CNAME to npm's registry (thus breaking yarn).

Reminds me of a recent Yarn problem, overwriting which(1). https://github.com/yarnpkg/yarn/issues/4205

There appear to be no unit tests for their entire lib/utils folder. Which includes things like this (misguided) chown utility. https://github.com/npm/npm/tree/release-next/test - and note the lack of testing in the commit linked in the bug report. I had an inkling that NPM was cancer, but not like this. Yarn, by contrast, has everything you would expect of a Facebook-engineered library: https://github.com/yarnpkg/yarn/tree/master/__tests__/util Will be closely evaluating a switch to Yarn for our live apps. This is simply sad.