Please everybody remember that Bower is only a means to an end and actually has no relevance to your run-time environment. Once files exist on a server somewhere, it does not matter whether they were obtained via Bower, Zip, npm, Git, etc.
The actual rule is this: from the _client's_ perspective, all components come from a single folder. Now, It's absolutely true that rule is limiting, and we are working on improving the situation in various ways, but mostly this involves changing HTMLImports spec which is a laborious standards process. We also acknowledge the problem with de-duplicating concatenated resources. If `imports.html` includes `core-ajax.html` there is no way for HTMLImports to understand that. This is something we are also working on at the spec level, and something we are trying to address in Vulcanizer. Re: versioning, the strategy today is that one must handle this at the project level. Whatever `<components>` folder a page is using must be populated with the correct component versions for this project. If the project has component A that requires C.v1 and component B that requires C.v2, this is an fundamental incompatibility that one must resolve by updating A or removing one of A or B. I expect to get approximately a zillion replies about how this is not acceptable. All I can say is that we do understand the consequences, but this is the reality for now. On Fri, Jul 11, 2014 at 11:25 AM, 'Ian MacLeod' via Polymer < [email protected]> wrote: > > > On Fri Jul 11 2014 at 11:01:05 AM, Michael Bleigh <[email protected]> > wrote: > >> Thanks for the links! That's super-helpful. Completely agree that >> import-time is the right time to tackle this. Also agree that it's possible >> that a new spec would need to be added to really make this work. >> >> Unless I'm misunderstanding, it seems like the security concerns wouldn't >> be that big of a deal. You should never, ever be importing content from a >> source you don't already trust, so some form of resource hashing seems like >> it would only be an efficiency/deduplication issue, not a security issue. I >> can imagine something like a "unique" or "once" attribute on <link> that >> would basically say "don't load this resource if it's already been loaded." >> However this would require fetching and hashing the resource (or having an >> agreed-upon header to respond with in HEAD to verify the hash), which means >> you're still sending the data over the wire. >> > > Yeah, you're right here - the hashing approach really only tackles > *identical* resources, and your suggested approach below nicely > circumvents that :) > > >> One way to manage this in a way that leaves most of the solution up to >> userland (which is imo a good idea in most cases) would be to have an >> attribute on the link tag called e.g. imports that would be a >> space-delimited token attribute. The idea here would be that if the >> resources specified by imports are already loaded (or already being loaded >> from an uncomplete import) they are simply skipped. Of course a <link> tag >> without this attribute would load regardless. To illustrate what I mean, >> imagine something like this: >> >> <link rel="import" href="https://api.github.com/wc/repo.html"; >> imports="core-ajax >> github-repo github-user"> >> > > I like this! Best of all it's *simple* and *obvious* to the user. > > >> You would want to have some kind of canonical API to be able to >> manipulate imports via JS as well, something like document.imports. OK, so >> this would solve some of our problems but leave others: >> >> 1. What about conflicting versions of an import? We could do >> versioning e.g. [email protected] but we can't really expect to put >> semantic versioning into an HTML spec. >> >> I tend to agree, after watching various communities try to adhere to > semantic versioning to varying degrees of success, it seems too > heavy-handed. > > Why not just treat them as strings? You could even cheat a little: > > <link rel="import" href="https://api.foo.com/bar.html > <https://api.github.com/wc/repo.html>" imports="bar-awesome bar-awesome@0 > [email protected] [email protected]"> > > This example is probably overkill, but is certainly flexible. > >> >> 1. Depending on the import, that "imports" list could become very >> long indeed. >> >> > >> 2. is a mostly aesthetic concern and I suppose the length of your imports >> list would be determined by how much you care about dependency >> deduplication. >> >> 1. is a much trickier issue, and to solve it I would propose that you be >> able to actually reach in and define the import resolver yourself. For >> example, document.imports.resolver = function(import){ } >> > > Starts to sound pretty similar, mechanically, to ES6 modules > > >> If you did that, you'd be able to slot in something for whatever system >> you like that maybe *would* understand semantic versioning and throw errors >> when versions are too mismatched but allow minor version incompatibilities, >> etc. You could even theoretically feed it configuration a la bower.json and >> let it run from there. >> >> Eric's HTML5 Rocks article is titled "HTML Imports: #include for the >> web". I think that's a fantastic ideal but one that isn't quite being lived >> up to yet. Until we're able to properly resolve dependency conflicts and >> multiple imports, we're not going to be able to simply import and forget >> it. Obviously the Polymer team is running head-on into this issue by the >> universal use of Bower, a third-party package manager. >> >> I know there has to be a way to do this natively in a way that still >> allows for proper userland expansion. Anyways, thanks for taking the time >> to listen to my rambling, would love to discuss further. >> >> On Friday, July 11, 2014 10:35:24 AM UTC-7, Ian MacLeod wrote: >> >>> Here's some previous threads that might help spur some discussion: >>> >>> - Canonical CDNs? >>> >>> <https://groups.google.com/forum/?fromgroups=#!searchin/polymer-dev/cdn/polymer-dev/Dz6yIqMO2cc/1w2957gLXs4J> >>> (not really) >>> - Centralized components host? >>> >>> <https://groups.google.com/forum/?fromgroups=#!searchin/polymer-dev/import%7Csort:date/polymer-dev/Dz6yIqMO2cc/BdPd1KJhbUQJ> >>> - AMD/requirejs + imports? >>> >>> <https://groups.google.com/forum/?fromgroups=#!searchin/polymer-dev/import%7Csort:date/polymer-dev/bdSyt-QXFE8/ohRr1ucTRYMJ> >>> - ... and some others that I'm totally failing to find :( >>> - Also, there's core-shared-lib >>> <https://github.com/Polymer/core-shared-lib> which sorta tackles this >>> >>> >>> It feels like it's best to tackle that at import time (as opposed to >>> registration time) - purely for reducing bytes over the wire. Though, it's >>> not clear how to do that w/o adding a ton of complexity to imports. >>> >>> It'd be interesting to have some sort of scheme where you can identify >>> assets via some means *other* than a URL. Probably some sort of hash, >>> cert, or signature. Doing it in a secure way would be challenging, though >>> >> >>> On Fri Jul 11 2014 at 10:19:43 AM, Michael Bleigh <[email protected]> >>> wrote: >>> >> Something that I've been thinking a lot about lately is the idea of >>>> companies offering importable elements instead of their existing JavaScript >>>> APIs. So Mixpanel, or Google Analytics, or even GitHub would, instead of >>>> saying "load this JS" just say: >>>> >>>> <link rel="import" href="https://api.some-company.com/api.html";> >>>> >>>> Which I think is a fantastic and exciting premise! What isn't as clear >>>> or exciting is how to manage the potentially conflicting dependencies. >>>> Let's say that the imported API element uses core-ajax but so does my >>>> application. How is that conflict resolved? >>>> >>>> Of course Bower solves this by simply only having one of a given >>>> dependency, but we're talking about the Web Platform here and Bower, cool >>>> as it is, isn't really core Web Platform tech. Not to mention that there >>>> are big potential wins to being able to import an always-up-to-date API >>>> directly from the source. >>>> >>>> Right now it *seems* as though first-to-register wins. I see errors in >>>> my console if an element tries to be registered twice. But I'm not certain >>>> whether the Polymer behaviors are likewise ignored, are re-applied to the >>>> existing definition, or what. >>>> >>>> Basically I just think this is something that merits some thought and >>>> discussion, and I'd love to hear what you all think. >>>> >>>> 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 [email protected]. >>>> >>> >>>> To view this discussion on the web visit https://groups.google.com/d/ms >>>> gid/polymer-dev/93ab4fd9-adba-49a3-9368-03e6f5166509%40googlegroups.com >>>> <https://groups.google.com/d/msgid/polymer-dev/93ab4fd9-adba-49a3-9368-03e6f5166509%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> 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 [email protected]. >>>> >>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/polymer-dev/4b09301e-053a-4402-8d2d-1afb1e5490dd%40googlegroups.com >>>> <https://groups.google.com/d/msgid/polymer-dev/4b09301e-053a-4402-8d2d-1afb1e5490dd%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>> >>> >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/polymer-dev/CAKc-BFiSTPCi3K9r8jFRVYYCLTUGoVdgPKULOpOoMsRk7_Hwpw%40mail.gmail.com > <https://groups.google.com/d/msgid/polymer-dev/CAKc-BFiSTPCi3K9r8jFRVYYCLTUGoVdgPKULOpOoMsRk7_Hwpw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/CAHbmOLZiqEuY080K7gMkuKwcdw%3D2k4BtPWh0vstS-6k6t%2BfERA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
