Add component.json #1

wants to merge 1 commit into


None yet
5 participants

This will make the library work with component


substack commented Dec 3, 2012

Why can't component just use what information already exists in the package.json?. There are no static assets in this module. I'm not going to add this file.

substack closed this Dec 3, 2012

Raynos commented Dec 3, 2012

👍 component should read package.json

Raynos commented Dec 3, 2012

@visionmedia can some part of the component stack handle parsing package.json as a fallback somewhere to avoid duplication of information.

That's not to say don't use component.json. It's to say support loading non-component modules without them having to add a component.json file. It's far less work to patch component to make a best guess at reading package.json which is really easy for modules that have a single index.js entry point.

tj commented Dec 3, 2012

The reason I dont want fallback support is because the dependencies are fundamentally incompatible since npm is just one large namespace, so it would only work for modules like this with no dependencies. We've already gone down the "just namespace in package.json" route and it was pretty terrible, in fact we're still using that for our app because we haven't finished migrating

Raynos commented Dec 3, 2012

@visionmedia github is also one large namespace. Just have component figure it out or component people wont be able to use code from browserify+npm people.

tj commented Dec 3, 2012

not really, we can all name things whatever we like without collision, thus they're fundamentally incompatible

Whilst not technically impossible (component could use browserify when it detects a dependency that has a package.json and not a component.json) It would require consumers of the component format to understand npm, browserify, package.json files etc.

One of the founding principles of component is that it's an easy format to consume, e.g. creating a component.php which integrates with Drupal shouldn't be too difficult. This kind of bloat would prevent that. In addition, because we have a two level namespace, I can just fork rolling-reduce and use the forked version directly (npm's git urls only work if you have git installed, so they're not comparable).

guybrush commented Dec 7, 2012

i thought about working on component-npm(1) and npm-component(1) - its somehow like git-svn (where svn doesnt suck)

1) component-npm install <npm-package-name>
2) component-npm install <gh-user>/<repo-name>
3) npm-compontent install <gh-user>/<repo-name>

1) npm-registry -> npm       -> browserify -> component
2) github       -> npm       -> browserify -> component
3) github       -> component -> npm        -> browserify

so everyone can do his thing and everyone can use everyone's thing :D

guybrush commented Dec 7, 2012

@visionmedia regarding naming things whatever, how is component different to npm?

  • npm
    • {"name":"bar","version":"0.0.1","dependencies":{"foo":"userX/foo"}}
    • npm install userX/bar
  • component: component install <gh-user>/<repo-name>
    • {"name":"bar","version":"0.0.1","dependencies":{"foo":"userX/foo"}}
    • component install userX/bar

tj commented Dec 7, 2012

@guybrush yeah I saw that isaac added support for that after component, but regardless most packages (all of them?) do not define their dependencies that way, either way many will not so it's still a broken concept

Raynos commented Dec 7, 2012

"dependencies": { "foo": "userX/foo" } doesn't allow for saying I want "foo" at version ~0.2.3 so it's kind of useless.

guybrush commented Dec 7, 2012

@visionmedia right most (i dont know of any but some deployment stuff i do my own) packages dont git-dependencies.

anyway i dont see where the concept breaks, imho its just a matter of how you look at the things.

npm is not only about the npm-registry, for me its all about everyone agreeing to put dirs with package.json or index.js in it into node_modules to handle dependencies. where and how i get those dependencies from is not so important (of course it its, but way less than dependency-definition/resolution).

but these are just my thought, i am not the guy with 100+ usefull opensource projects.

tj commented Dec 7, 2012

it's kinda like node and coroutines, you cant really have them both, it just doesn't work well, you really need to start from the ground up with a core concept

guybrush commented Dec 7, 2012

@Raynos substack once said in #stackvm that it would be cool to have npm look for git-tags and run semver+regexp on it. i think that would be cool

also you can do npm install <user>/<repo>#<gitref>

btw we should cache git-repos with npm :p isaacs/npm#2482

Raynos commented Dec 7, 2012

Yeah We actually have deps like

    "x-class": "git+ssh://",
    "x-user": "git+ssh://",

Being ablue to do Company/x#0.1.x would be cool

guybrush commented Dec 7, 2012

@Raynos hey cool idea, just implement semver with branches. one could even use git-hooks for that

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment