Plan for components that declare Bower dependencies on different versions of Polymer?

[Jan Miksovsky]

I was just trying to use a component whose bower.json turned out to declare a dependency for "polymer": "~0.1.4", with a hard-coded version number. The rest of my project declares a similar dependency for "polymer": "Polymer/polymer#master" to get the latest version. When doing a Bower update, Bower indicated that I needed to resolve this conflict by picking which version of Polymer I wanted for the component called "polymer". Urk. While it's easy enough for me to tell Bower which version of Polymer to use, I now have no guarantee that the component requesting a specific version is going to run. (In fact, it doesn't.)

This seems like a dependency management problem of the first order. Is there some plan for how Polymer projects will eventually be able to include components that depend on different versions of Polymer?

Part of this problem appears to be a Bower issue (not Polymer): as far as I can tell, the installed set of components ends up as a flat folder structure within the /components folder. Even if this is a Bower problem, though, Polymer's de facto standardization on Bower makes this a potentially limiting issue for the Polymer ecosystem.

A separable part of the problem is the need to load multiple versions of Polymer simultaneously. Has that been ruled out? I recall that jQuery ultimately had to concede that, in practice, one couldn't always depend on every part of an app and every widget being constantly maintained to run with the very latest version of jQuery, and had to come up with a strategy supporting multiple versions running on the same page.

[Scott Miles]

The notion that one cannot always use something that requires version X of a thing with version Y of that thing is inherent in the concept of versioning. 

Polymer is advocating a high-granularity, high-reuse model. Any such model is particularly susceptible to version pain, however Polymer is really not breaking new ground here.

Once we reach a stable version number, then, like many projects, we will document a contract about restricting API-breaking changes to major version number increments, or something along those lines. At that point, packages will need to use bower ~ syntax to select an appropriate version range.

In my opinion, using multiple versions of any library in a single project is a dramatically bad idea. I also suspect that, once we achieve stable, Polymer will not need to evolve nearly as rapidly or as often as JQuery. Having said that, there is nothing we are doing to block eventual support for multiple versions in one project if it turns out I'm wrong.

Follow Polymer on Google+: plus.google.com/107187849809354688692
---
You received this message because you are subscribed to the Google Groups "Polymer" group.
To unsubscribe from this group and stop receiving emails from it, send an email to polymer-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/33815a22-dedf-4067-8d6f-77a814ad0224%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Jan Miksovsky]

Scott: Thanks for sharing Polymer's perspective on this. I'm still unsure where that leaves businesses that want to include a variety components which aren't all developed in lock-step.

Let's stipulate that Polymer is a special case in a number of ways. It's big, for one thing, and patches the browser in all sorts of ways that might make loading multiple versions challenging. Polymer's also got a sizable full-time team behind it that can maintain the project in perpetuity. Let's further stipulate that Polymer has a focused role that, once finished, will not change much in the future — and, hence, won't be subject to many breaking changes. Finally, Polymer has a non-trivial set of interrelated components whose deployments are closely coordinated by the team.

So let's set all that aside and consider the question: what about all the other components? Suppose components X and Y depend on some useful building block Z. Perhaps X and Z are actively maintained by teams, but Y is an evening hobby project for a single person. The day Z includes a breaking change that X wants to track — but which Y can't track yet (or ever) — the project including both X and Y is horked, no?

We could say that tracking all this is the responsibility of the project owner. If the makers of X, Y, and Z are very careful about versioning, perhaps the project owner can follow along closely enough that to see that they can't use the latest X yet, because that depends on the latest Z, and Y's still requires an older, incompatible Z. If the project owner is lucky, Y might update quickly enough. Or maybe the author of Y is off doing other things. Y still works on its own, but in practice it's useless because its dependency on an old Z makes Y unworkable in apps that include the latest and greatest X.

And all this complexity is in a tiny, toy case where the project owner can follow the dependency chain without too much trouble and work out which versions they can use. But I already have components with small, bushy trees of dependencies several levels deep. I think it'll be too much to expect someone to carefully walk through all the dependencies for every component their project includes to work out potential incompatibilities. That is, the "high-granularity, high-reuse model" creates enormous work. Even if Polymer itself closely manages backward compatibility and versioning, it's unlikely every component vendor will proceed as carefully.

I'm just expressing a concern that dependency management feels like an underexamined (or under-documented?) aspect of the component ecosystem. In practical terms, I'm concerned this will limit the ability of businesses to freely include components from different vendors who aren't closely coordinating their actions.

[Scott Miles]

>> Polymer ...[is] big, for one thing, and patches the browser in all sorts of ways 

This is `platform.js` you are talking about which must be considered independently from Polymer itself.

>> And all this complexity

You provided a lot of commentary there, but nothing that struck me as novel from a versioning perspective. As long as there have been libraries, this has been an issue.

>> where the project owner can follow the dependency chain

The project owner need not do that. Component A may involve a 'bushy tree' of dependencies, but they all flow from Component A. If Component A is a compatible version, that's all you need to know.

Scott

To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/712b5667-05d2-4adb-9fcb-b50e7cf9cdeb%40googlegroups.com.

[Brian Di Palma]

Jan there is a solution to the issues you are worried about and it's called npm.

npm gives you the option but not the obligation to load multiple versions of the same dependency.

That's one of the main reasons that I would recommend it for large, complex applications.