Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
denji opened this issue Mar 3, 2015 · 8 comments
Closed

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

denji opened this issue Mar 3, 2015 · 8 comments

Comments

@denji
Copy link

denji commented Mar 3, 2015

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

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).

screenshot

@cjihrig
Copy link
Contributor

cjihrig commented Mar 3, 2015

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

@cjihrig cjihrig closed this as completed Mar 3, 2015
@piscisaureus piscisaureus reopened this Mar 4, 2015
@piscisaureus
Copy link
Contributor

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
Copy link
Contributor

tellnes commented Mar 4, 2015

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
Copy link
Member

Qard commented Mar 4, 2015

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
Copy link
Contributor

othiym23 commented Mar 5, 2015

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
Copy link
Contributor

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
Copy link
Contributor

rlidwka commented Mar 6, 2015

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
Copy link
Contributor

Related to #362 and #252

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants