Is component just a package manager or not?

[em]

The direction I see component going is it has been minimizing its scope and becoming just a package manager - which I think is great. The readme still claims it is a "full vertical integration stack", which to me sounds like another homogenous web framework instead of a package manager with a standardized component.json that any tools can be made to support.

What exactly are the current goals for component? Any chance it can be codified as a package manager and nothing more - with component-builder being a separate thing?

[jonathanong]

nope it's both. with component you can just think of "packages" without the "management" and just build your app.

[em]

That's really disappointing. I don't think anyone wants that. I think everyone just wants a package manager for the web that has a consistent API (unlike bower) and uses synchronous node-style modules. Really all I ever wanted was npm but with the expectation that the modules don't require('fs').

Everything else that is a part of the component stack can be built on top of the basic standard offering of a standard component.json spec, and component(1). Why make the core component project do so much other stuff? It's like npm implementing require().

The reason I'm asking is because of this project I am working on: https://github.com/em/elem

I have the unique ability in this context, to implement my own require() and parse component.json myself. There is no need to use a component-builder in this circumstance, it's something you can get for free. But I keep asking myself, is this something that even bodes with the component philosophy? Is this a project that doesn't want alternate consumption of components? I really wish it did, because it opens up the doors for component to be less of another web framework, and move closer to being the standard for distributing browser libraries.

[cristiandouce]

I believe for that you have this: https://github.com/component/resolver.js

Which is a component(1)'s core component.

[em]

My project is extremely different. But I'm not trying to show you my project. I'm trying to urge you to brand component as a package manager, and reference things like builder and resolver as component consumers, so that other people like myself can consume components independently in a sanctioned way, and try to further the proliferation of components as a whole.

People understand that the web needs a package manager, and that bower is far too agnostic to be a real solution. We need a package manager first, and then we can have those other things. I think component trying to be so many other things is preventing it from being adopted.

[em]

Part of that is including things that people expect like component update in component(1). And promoting certain libraries to first-name basis, so I can just do component install page rather than component install visionmedia/page.js

[tj]

npm is generic/fragmented if that's what you want, component is/was an attempt to unify things. Over all it's just a concept, you can do whatever implementation you like, but we'd like things to work out of the box

[em]

Bower and component both competing to be the package manager for the web, yet neither of them actually being a complete package manager that can version and manage agnostic packages w/ a common interface, really really bums me out. Just saying.

[tj]

but if you want just a generic tarball you could use npm, but that's where all the unwanted fragmentation steps in

[em]

The problem with npm for the browser has never been anything more than the fact that you need to know ahead of time if what you're installing is going to at some point try and require a core node module it doesn't really need and blow up. The solution for that is just to have a place to put modules that are supposed to be run in the browser. You could even implement some core modules like 'path', they'd just need to be dependencies in the browser because bytes cost something in that environment.

[em]

The way I see it, a package manager has a unique and noble role, unlike other projects. It has to be somewhat unopinionated like bower, but it also has to provide a common interface unlike bower. Module authors need a definitive way to expose their API, and consumers need a definitive way to use it. Neither component or bower are providing that. The end result is the community is split even further.

What I'm suggesting - is just that you consider branding component as a pure package manager and focus on that aspect of it. Get the web frameworks out there on board with consuming components as opposed to making their own package managers. If they are using component, then it feeds back in to the component community, and people can finally author libraries that can be used in many places with semantic versioning, search, update, all the stuff you want from a package manager.

Right now we have tons of popular web frameworks. But they only last a few months before something better comes along. If component takes this direction, then the next generation of web frameworks can share components at their core. I want to see component be a commodity of other frameworks, not a framework itself.

[tj]

That's what component does, define a way to unified structure client-side packages. If it were "pure" it would have no notion of unified contents, thus it would lead to fragmentation. Once web components are real and well supported then tarballs will be just fine, but until then that's not feasible unfortunately.

[em]

I don't think we disagree.. I simply think the current readme does not reflect the ultimate goal of component to be reduced to a package manager for es6 web components. Most people I know think component is something else. Just trying to give you an outsider's perspective.

[jonathanong]

we can discuss this in #components. this discussion doesn't really belong here

[em]

Oh ok. Sorry.

[tj]

it is something else, right now and for the foreseeable future at least. eventually some day it'll be tarball fetcher for es6 stuff, but that'll be a while