Install Backbone does not install dependencies #172

Closed
alexstrat opened this Issue Dec 4, 2012 · 56 comments

Projects

None yet
@alexstrat

I'm doing:

$ bower install backbone

But I don't get Underscore installed as dependency. See my bower list --map (with jquery-ui as additional successful example). Backbone part is empty !

{
  "backbone": {
    "source": {}
  },
  "jquery": {
    "source": {
      "main": "components/jquery/jquery.js"
    }
  },
  "jquery-ui": {
    "source": {
      "main": "components/jquery-ui/ui/jquery-ui.js"
    },
    "dependencies": {
      "jquery": {
        "source": {
          "main": "components/jquery/jquery.js"
        }
      }
    }
  }
}

Why ? I noticed that backbone git repo does not include a component.json. Is that related ? In this case, should not bower use package.json ? Is there an other repo to use ?

@satazor
Member
satazor commented Dec 4, 2012

@alexstrat it's exactly because it does not include a component.json and we removed the package.json fallback support since v 5.0.0.
For now you can simply do npm install --save underscore to do it manually and make a PR to the backbone guys, adding the component.json

@satazor satazor closed this Dec 4, 2012
@satazor
Member
satazor commented Dec 4, 2012

Oops, didn't mean to close.
@alexstrat If they refuse to add one, we can make a mirror it in https://github.com/components.
Please let me know how it goes.

@satazor satazor reopened this Dec 4, 2012
@alexstrat alexstrat referenced this issue in jashkenas/backbone Dec 4, 2012
Closed

Add component.json for Bower support #1867

@alexstrat

Okay thanks, i've done it also for underscore.

But I tried to install backbone coming from my own repo (https://github.com/alexstrat/backbone) I don't get underscore neither:

$ bower install git@github.com:alexstrat/backbone.git

Something to do with tags ? :/

@satazor
Member
satazor commented Dec 4, 2012

Yes, bower fetches the last tag or the latest commit if no tags are available.
Though we will implement ways to get over it, please take a look at: #107

@alexstrat

Hmm okay..

So as you see in @jashkenas's comment, backbone and underscore people are not ok with adding a component.json. Their reason seems legit..

So, we need a mirror for both underscore and backbone, I think.

@satazor
Member
satazor commented Dec 4, 2012

For me it doesn't make sense. We had package.json support but there was much more disadvantages then advantages. For instance, people specified libraries that where only available in the npm and bower could not fetch them.

I was expecting the backbone team to reject the PR, they are not very permissive people. Anyway, we can mirror the backbone repo in our own components.

//CC @paulirish @addyosmani @sindresorhus

@sindresorhus
Member

Not at all surprised either. Let's mirror it. Need to find someone to help keep them up to date.

@alexstrat

Is there a way to keep this mirrors up to date automatically ?

@addyosmani
Member

I agree that we should mirror it. Its going to take a while before
framework authors broadly adopt a component.json file.

@satazor
Member
satazor commented Dec 4, 2012

@alexstrat At the moment there isn't. We hope the community to slowly adopt bower until it become a standard.
Hopefully this mirroring stuff is temporary.

We indeed need someone to maintain it, preferably a recurrent backbone user.

@jashkenas

I realize that this ship has already sailed for Bower a long time ago, but since I got pinged on this ticket -- here's my two cents:

Asking every JavaScript library in use today to add an additional configuration file is not acceptable. That's what folks have done in the past, and if you want to support all of the package managers, you currently have to do:

  • package.json
  • component.json
  • “jam”: {}
  • index.js
  • main.js
  • “bpm”: {}
  • seed.js
  • “volo”: {}
  • “mappings”: {}
  • “ender”: {}

... and so on, and so forth. It's pretty silly, especially when you consider that all of the above configuration is asking for the same information: What is the name and version of the library? What are the client-side dependencies? What are the server-side dependencies?

If, instead of adding an additional configuration file, you figured out a way to get those pieces of information answered within package.json (the file that most other package managers already (ab)use), perhaps in consultation with the npm folks ... that would be wonderful.

@satazor
Member
satazor commented Dec 4, 2012

@jashkenas The problem with package.json is that it specifies dependencies for the node environment, not for the client environment. Using it to specify dependencies for the client side is wrong.

We long supported package.json fallbacks and what happened is that it caused a lot of errors and confusion, simply because some dependencies where registered in npm (and only work in node) but not in bower's registry.

@satazor
Member
satazor commented Dec 4, 2012

Also people that are publishing client side only packages in the npm because it works with npm install, are doing it wrong. They are polluting the npm registry with stuff that won't run in node. It's like using php's composer to fetch java packages.

@marcooliveira
Contributor

I see both points of view. I agree that there are too many solutions out there, and having all maintainers support every package manager is just not doable. Still, I also agree that package.json is not an absolute solution right now.

I think everyone here can agree to these terms. Now, instead of trying to get everyone to support each one's package manager, why not gather all the package managers, and try to come up with a unified solution? Some guys in here have enough pull to see this happen, I think.

@addyosmani
Member

I've been thinking a lot about a unified (or rather, interoperable) config spec for package managers lately and I definitely see @jashkenas point of view from the framework author perspective. No one is going to want to support N additional config files. At the same time, @satazor has a valid point about us avoiding pollution of the npm registry.

What I would propose is that (at some point), we should kick off discussions with Jam, BPM, Ender and so on and try to see if we can hammer out a solution. The alternative is to press ahead with the hope that our solution (i.e Bower) becomes the most dominant and other solutions have to figure out interop as a part of their own stories.

@necolas
Member
necolas commented Dec 9, 2012

AFAIK, Jacob and Alex already spent time having those discussions when Bower was being developed. Those package managers took different approaches and it seems to me that they haven't been particularly successful. Bower and Component have momentum although approach the problem in different ways. It's unlikely that you'd ever want or need to support every package manager, which is why no one does.

@satazor
Member
satazor commented Dec 9, 2012

For the time being we need to mirror the backbone repo. @alexstrat would you be interested in maintaining it?

@vendethiel

I suppose the need to mirror repos for libraries with a build system will never change tho.

@robfletcher

Would an alternative approach be to support a syntax in component.json that would allow the consumer of a dependency to restrict the files included from the dependency's git repo. e.g. for backbone I could do something like this:

{
    "dependencies": {
        "backbone": {
            "version": "~0.9.9",
            "includes": [
                "backbone-min.js"
            ]
        }
    }
}

That way there's no need to maintain a mirror.

I don't think the syntax above is ideal, obviously, as it conflicts with the standard name:version format but the general idea could be implemented in a number of ways.

@alexstrat

@satazor, let's say I'm an occasional user of Backbone.. but not of Bower (bower install backbone was actually my first try..).

But let's also say I'm okay with that.. What should I do ? Backbone just upgraded to v0.9.9: how several version of backbone can be mirrored ?

@medikoo
medikoo commented Dec 17, 2012

@satazor package.json is for defining dependencies for given package, not for node environment. It's actually the package that may be just server-side, cross-environment or just client-side, package.json is totally neutral in that.

I host on npm many cross-environment and even client-side only packages and it plays very well.

@medikoo
medikoo commented Dec 17, 2012

@satazor and NPM is officially blessed to be used for any-side packages. Saying that you should not host there client-side stuff is totally wrong.

@satazor
Member
satazor commented Dec 17, 2012

@medikoo your wrong, npm stands for node package manager, which means that is a package manager for stuff that runs on node.

Quoting: "Package manager. Installs, publishes and manages node programs."

Hosting cross environment packages in npm is fine as long as node is one of the environments.

@satazor
Member
satazor commented Dec 17, 2012

@robfletcher the problem is that the backbone has a dependency (underscore) that is not declared in the component.json (they do not have a component.json). At the moment the solution is to install underscore separately with bower install underscore --save or mirror backbone.

@alexstrat if we mirror backbone, we will be tagging the repos, just like the official one.
bower install backbone will install the latest version (last tag). If you do bower install backbone#0.9.8 will install that specific version.

@robfletcher

@satazor I completely get that but there's an associated problem that without the repo specifying a component.json bower will pull down the entire repo not just the published artifacts.

@satazor
Member
satazor commented Dec 17, 2012

@robfletcher, yes that's another issue and, at the moment, even repos that have a component.json will have all stuff pulled own. That's in our roadmap. Anyway, it would be good to have that for repos that do not have a component.json. Can you suggest that in #145?

@medikoo
medikoo commented Dec 17, 2012

@satazor npm doesn't stand for "node package manager". npm was made initially for node, but it's not restricted for node only packages.

Please, get to know more about subject, before making false statements that just misguide people.

@satazor
Member
satazor commented Dec 17, 2012

Yes, it means Node Packaged Modules (my bad) which is essentially the same. Look at what I quoted above.

@robfletcher

@satazor looks like what I'm asking for is already covered by #168

@medikoo
medikoo commented Dec 17, 2012

@satazor

Hosting cross environment packages in npm is fine as long as node is one of the environments.

Where did you read that? :) It's totally false.
There are already many client-side only packages on npm that can be bundled for browsers with tools like Webmake or Browserify

@satazor
Member
satazor commented Dec 17, 2012

@medikoo the fact the they are doing it, means it's right?

@medikoo
medikoo commented Dec 17, 2012

@satazor I'd rather ask, what made you think it's wrong?

Fact is, that's the best way to reuse same modules in both environments without single line of boilerplate, or double configuration problem.

@satazor
Member
satazor commented Dec 17, 2012

Put yourself as a node only user. Would you like to have your central package registry polluted with stuff that does not work in node? It's true that it's all JavaScript, but in the end, all those client side packages (or almost) will not work in node. What if people also used npm to host php or java packages? Sure, npm can probably handling the fetch and installation of those, but again, they will not work in node. Do you think that this is correct?

@satazor
Member
satazor commented Dec 17, 2012

@medikoo As I said, it's fine to publish packages if they work in node (but they also can work in the client side). Nobody said that npm couldn't be used to host client side packages, java packages or php packages. It's my humble opinion and common sense.

@medikoo
medikoo commented Dec 17, 2012

@satazor I don't see any problem with that.

You search repository for packages that are solution to your problem, it's natural that if you look for some e.g. ajax driver, results won't pollute with server-side only packages. Same way if look for solution that addresses server-side API, there won't be client-side packages as this API is not provided on client-side, and if package addresses generic API available on both sides, it's just double win.

You should rather think API-wise and do not put bold line between client and server, it's same language that works on both sides.

@satazor
Member
satazor commented Dec 17, 2012

@medikoo My opinion is that, packages like async that work in node and the browser are fine to publish in npm. But publishing jquery plugins, dom libraries and other stuff that only work in the browser is consired, by me and many others, a bad practice. But that's just opinions.

@satazor
Member
satazor commented Dec 17, 2012

It's true that many libraries share the same API for node and the client-side. But I'm not against those being published in the npm. I'm against browser only libraries being hosted there.

@medikoo
medikoo commented Dec 17, 2012

@satazor but then question is why use two different managers for cross-env and client-side env packages?
What if we want to use both of them in same project, that's problematic, we should use one JavaScript package manager not few.

@satazor
Member
satazor commented Dec 17, 2012

@medikoo that problem already exists if you use npm to fetch client side packages. What if the package your trying to use doesn't exist in npm? For instance, you got a client-side project that is using async, jquery and some jquery plugins. You will end up managing the jquery plugins yourself because those aren't in the npm registry. In this case npm is not covering all packages and you end up manually handling them.

If you use bower, you got a much variety of endpoints to fetch packages. You have git endpoints, local repositories, URL's, tarballs and zips. In the example above, bower would be able to fetch async, jquery and the jquery plugins.

In my projects, I manage client side packages with bower and node packages with npm (build scripts, mocha tests, etc).

@satazor
Member
satazor commented Dec 18, 2012

There's a lot more reasons attached to this subject. One of the most important one is the nature of node and npm. Node allows different versions of the same package to live within the project. That's ok in node because that's
how it was designed to be. In the clientside you simply can't have multiple versions of jquery, jquery plugins and many other stuff. Firstly because they (probably) will overwrite eachother and secondly because your app will increase a lot in size due to duplicated stuff.

@medikoo
medikoo commented Dec 18, 2012

@satazor It's flawed reasoning, jQuery wasn't written as CJS module, it was written when no dependency managment or package managers where on a horizon, and it just exposes itself in old primitive way on global namespace. It's not a module in a CJS or upcoming ES6 sense, therefore it raises the trouble if you try to treat it as one.

The way NPM handles versions is on of it's biggest advantage, it doesn't share flaws that e.g. Python or Ruby package managers are equipped with, and as we build now very complex applications also for client-side, this kind of versioning is also very important over there. Thing that it uses it's own repository it's also very important. Relying on external totally unrelated sources is short-sighted, at some point one of it may die and then your package manager is doomed. If your serious about it, your package manager should own its repository.

So saying that, currently I don't see any alternative to NPM. We need one package manager that addresses both server and client side, so we can reuse same code on both sides without a hassle, and one that has decent version handling, NPM provides all of that. Unfortunately every new package manage that appears recently just adds confusion without solving any problem, but adds many like subject of this issue.

@marcooliveira
Contributor

Although I'm not a fan of using NPM to manage client-side dependencies, I see some valid points from @medikoo. Still, I see a major flaw in this discussion. Regardless of personal opinions and flavours, when it comes to managing dependencies, we must not forget that whatever package registry we use, it will NEVER contain all the dependencies. Having that in mind, a package manager must provide a way to install these heterogeneous dependencies.

Btw, I think this discussion has grown out of proportion, and we should just agree that there is no one-size-fits-all solution.

As a final note, I must emphasize, I really dislike people polluting the NPM registry with irrelevant packages. People are "nom nom nom"ing useful package names like crazy, regardless of the tool quality or relevance. Taking into consideration that the curation process of NPM is practically non-existing, as it relies mostly on word of mouth, this creates a jungle of packages that is just overwhelming. This is why I do not agree with using NPM to manage client-side dependencies. (of course NPM could create mechanisms that could reduce or mitigate this issue, but this isn't the right forum for requesting that).

@satazor
Member
satazor commented Dec 18, 2012

The way NPM handles versions is on of it's biggest advantage, it doesn't share flaws that e.g. Python or Ruby package managers are equipped with

Yes the npm team offered a good solution but it doesn't work well for the clientside. Supposing that different versions of jquery could live together, would you deploy an app that has 5 different versions of jquery? My guess is no unless you want to deploy an app that is so big that nobody would use it.

We need one package manager that addresses both server and client side, so we can reuse same code on both sides without a hassle, and one that has decent version handling, NPM provides all of that.

NPM allows you to reuse server/client libraries. But besides having the issue described above, you will end up managing unregistered deps manually.
Since there was no package manager early on, packages are split over multiple endpoints. (Clientside) Package managers have to adapt to that, and this is exactly what bower did.

Still I understand your frustration in having to use multiple package managers to install and manage a project.
But you cannot say that NPM solves all these issues because it doesn't.

@techpines

@satazor you ever thought about hosting a simple registry of just "component.json" files for popular projects that resist bower?

You might have:

/bower-registry
    /backbone
        /component.json

And if bower couldn't find a component.json, in the github backbone repo (because they won't do it), then bower would check the registry and find it.

I know that would not be totally fun to maintain, but the community could make pull requests for the packages.

That way you could make positively sure that you had the 50 or so most popular javascript projects. Then you guys would have the leverage to finally force the package managers to take control of their projects by providing a sanctioned component.json.

Or just let the library guys update your component.json registry so they don't have to keep the file in their pristine libraries.

Just a thought! Cheers

@jdalton
Contributor
jdalton commented Feb 1, 2013

@techpines That's a pretty rad idea. 👍

@soswow
soswow commented Mar 2, 2013

The initial discussion was 3 months ago and users still don't get underscore when they install backbone =\

@mehcode
mehcode commented Mar 2, 2013

Backbone doesn't have strict dependencies. Even underscore could be replaced by lodash (or loscore). Until bower can implement a sort of provides system (eg. lodash could say in its component.json that it provides underscore) then backbone shouldn't declare its dependencies.

@soswow
soswow commented Mar 2, 2013

@mehcode What do you mean? https://github.com/documentcloud/backbone/blob/master/package.json ->

"dependencies"  : {
  "underscore"  : ">=1.4.3"
},

It looks like discussion ended up with decision of making own clone in /components repo, but it looks like it's not there yet.

@jdalton
Contributor
jdalton commented Mar 2, 2013

@soswow He means this:

Backbone's only hard dependency is either Underscore.js ( >= 1.4.3) or Lo-Dash.

@soswow
soswow commented Mar 2, 2013

@jdalton Yeah, I know. But for some reason in the packadge.js there is one. I guess the reason is if someone gets backbone with npm, then it will work out of the box. So, I expect the same thing from bower - if I define backbone as dependency in my project I assume bower will deal with it's dependencies and makes backbone work right away. (Isn't package managers are made for this after all?)

Anyway, my goal was just to remind that this is still an issue. I didn't want to continue the discussion =)

@jdalton
Contributor
jdalton commented Mar 2, 2013

@soswow Cool, ya interestingly enough if a module happens to require Backbone v0.9.9 or lower it will break when pulling in the dependency of Underscore >=1.4.3 when using the-popular-Backbone-pattern of _.bindAll(this) because Underscore v1.4.4 broke its _.bind compatibility.

@mehcode
mehcode commented Mar 2, 2013

@soswow I agree with you. Which is why I'm proposing the provides functionality. I'll open an issue to discuss and elaborate later.

@satazor
Member
satazor commented Apr 7, 2013

@techpines your idea is interesting, will note it down for future discussion.

@satazor
Member
satazor commented Aug 12, 2013

This is an old thread. Meanwhile, a shim repository was created as components-backbone, that includes the deps. All suggestions were noted for future discussion. Thanks everyone.

@satazor satazor closed this Aug 12, 2013
@acazacu
acazacu commented Oct 18, 2014

As I ran into this issue (dependency management) I fell back to npm, only to find that npm does not install backbone's dependencies due to an architectural decision that has been undergoing debate for 3 years now.

To everyones knowledge, the npm issue link: npm/npm#1341

By any chance, has the issue of dependency management been solved in any other package manager?

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