yapm is a package manager for node.js (npm fork)

[denji]

Suggest to add the possibility, as an alternative to the slower

• https://github.com/rlidwka/yapm

Changes

• improvements in package.json handling:
  • preserve formatting of package.json files
  • support for package.json5 and package.yaml files (docs, #3336, #4482).
  • if package.json or any other json document is malformed, show where the error is (#3869).
• formatting changes:
  • logs have much more clean formatting
  • added a progress bar showing download progress (#1257)
  • better search output with github repository links
• multiple registries support
  • registry-specific configs + security fixes
  • easier switch between different npm registries
• semver support for packages installable from github (docs, #3014, #3328, #3442, #3511, #4527).
• a bunch of other minor changes (docs, #4573).

[cjihrig]

Thanks, but we're going to stick with the official npm.

[piscisaureus]

There may be good reasons to stick with the official NPM, but we ought to have better reasons than "that's just the way it is".

Multi-registry support and github-semver support seem like useful features to me.

[tellnes]

yapm is a nice alternative to the official npm. I'm using it myself, but I don't uses it as my main package manager. Only for some projects.

Mainly I started using yapm for package.yaml support. The readability and possibility to add comments is a huge win when you are writing applications which has a lot of dependencies.

Switching to package.yaml does not come without some problems. Eg. browserify won't read the file.

The formating changes is also pretty awesome.

In my opinion a better solution would be if we could get this improvements in the official npm. But the official npm can't just land all patches everyone wants. One solution to that could be if npm where to implement some sort of plugin system.

[Qard]

I don't think this would happen because npm inc and @othiym23 are heavily invested in io.js and are working very closely with the io.js core team to get io.js shipping with up-to-date npm releases. yapm, on the other hand lags behind npm itself, and is @rlidwka no special effort to support io.js.

If you want the features of yapm, you are better off just requesting them in the npm issues. Or better, submit PRs.

[othiym23]

A few of the differences between the two are philosophical:

• package.json is the core metadata transport for the entire npm ecosystem, so replacing it with other formats is not going to happen. Yes, JSON is a terrible format for config files, but the last time I mentioned YAML positively in #Node.js, I got snowed under by people hating on it. Config file formats are an infinite bikeshed, and npm has opted for consistency across its platform and, as much as practicable, making the tool and not humans deal with JSON.
• The power of npm comes not so much from the CLI or the other software built by the npm team, but the incredible breadth and variety of the packages published with it, and the exceedingly vast majority of those are hosted on a registry (note the indefinite article – there are many private registries out there in very heavy use). GitHub dependencies are second-class in npm by design, because they just can't work as smoothly as a dependency resolution system that was designed from the ground up. This is why npm won't support semver range matching for GitHub branches – it opens up a huge new set of edge cases with no good resolutions. The feedback the CLI team has gotten from Bower users and developers, on the balance, supports this.

As for the rest, we're constantly adding new features to npm, large and small, and I am doing my best to get to people's pull requests in a timely manner.

It would be uncool of me to lobby one way or the other, given the conflicts of interest involved, so all I will do is echo @Qard and say that the npm team is committed to the success of io.js and will continue to be, regardless of whether npm continues to be the bundled package manager.

[Fishrock123]

Considering we have been talking about unbundling / more loosely bundling npm as it is, I don't think we'd ever bundle another / a different package manager CLI.

Also, npm is very widely supported and maintained.

[rlidwka]

yapm author here

Yeah, just stick with npm. Most of the features described above are re-implemented in npm now (my README is outdated, I'm sorry about that). And its support is a lot better.

---

That said, a talk about uncoupling npm from io.js installation should continue somewhere.

[Fishrock123]

Related to #362 and #252