I agree with Scott on the short comings of npm\bower. I have raised an issue on npm about the name `node_modules` but it seems that there will be no other name considered. Even to a fixed, generic, neutral one. There is also a need for some namespacing, as Scott was suggesting an organization one would make sense and should be enough for most, if not all, cases. I was thinking of suggesting that to npm; I didn't realise/think that bower already had something like that, a pro to bower imo.
Still, given all those issues package managers/depedency managers are part of normal future web development and that will only acclerate with ES6 modules around the corner. They are not perfect tools but their pros outweight their cons so their use will keep increasing, therefore it seems a good idea for libraries to be available via these tools. On Wednesday, February 26, 2014 6:43:44 AM UTC, Scott Miles wrote: > > Seems like we agree that Bower is not there yet. =P > > > On Tue, Feb 25, 2014 at 10:41 PM, Rob Dodson <[email protected]<javascript:> > > wrote: > >> Bower does not have an analogous relationship to the Web (at least, not >>> yet =P). >> >> >> Maybe not yet but someday... >> >> >> When you acquire Node you get npm right in the box. Those tools are >>> welded together. >> >> >> That wasn't always the case <http://howtonode.org/introduction-to-npm> :) >> >> >> On Tue, Feb 25, 2014 at 10:36 PM, Scott Miles <[email protected]<javascript:> >> > wrote: >> >>> On Tue, Feb 25, 2014 at 10:30 PM, Rob Dodson >>> <[email protected]<javascript:> >>> > wrote: >>> >>>> Your statement about building an ecosystem is entirely correct. The >>>>> notion that Bower search is the key to that kingdom I find entirely >>>>> dubious. >>>> >>>> >>>> I don't think it's the key—I don't think there is any one key—but it's >>>> a huge leg up. The search built in to npm/npmjs.org drives the node >>>> module ecosystem. >>>> >>> >>> When you acquire Node you get npm right in the box. Those tools are >>> welded together. >>> >>> Bower does not have an analogous relationship to the Web (at least, not >>> yet =P). >>> >>>> >>>> >>>> On Tue, Feb 25, 2014 at 10:15 PM, Scott Miles >>>> <[email protected]<javascript:> >>>> > wrote: >>>> >>>>> Your statement about building an ecosystem is entirely correct. The >>>>> notion that Bower search is the key to that kingdom I find entirely >>>>> dubious. >>>>> >>>>> If I make a GitHub repository for my new project, it's available via >>>>> GitHub search, Google search, and installable via Bower. If another tool >>>>> comes along, it will work too. >>>>> >>>>> I'm not suggesting that we never publish to the Bower registry, but I >>>>> will push back on any effort to lock ourselves into any one particular >>>>> registry or tool. >>>>> >>>>> >>>>> >>>>> On Tue, Feb 25, 2014 at 10:00 PM, Rob Dodson >>>>> <[email protected]<javascript:> >>>>> > wrote: >>>>> >>>>>> I want to use Bower strictly as a dependency management tool. The >>>>>>> rest of this stuff is scope-creep from that perspective. >>>>>>> >>>>>> >>>>>> Avoiding the registry means avoiding `bower search` and I think >>>>>> that's a very very big missed opportunity. If the success of polymer/web >>>>>> components relies on building an ecosystem then all channels of search >>>>>> are >>>>>> crucial to that success. The bower search channel is well established >>>>>> and >>>>>> we should leverage it. >>>>>> >>>>>> >>>>>> On Tue, Feb 25, 2014 at 8:10 PM, Scott Miles >>>>>> <[email protected]<javascript:> >>>>>> > wrote: >>>>>> >>>>>>> >> You can end up with multiple directories for the same stuff >>>>>>> >>>>>>> I don't see how this follows from using variations on the >>>>>>> <package-id> argument to bower. >>>>>>> >>>>>>> >>>>>>> >> Many people use bower's command line search tool >>>>>>> >> If we don't register our packages (polymer-ajax, for example) it >>>>>>> means someone else can squat on the name >>>>>>> >> It feels "un-bower" like to force people to use Owner/Repo >>>>>>> syntax. >>>>>>> >>>>>>> I want to use Bower strictly as a dependency management tool. The >>>>>>> rest of this stuff is scope-creep from that perspective. >>>>>>> >>>>>>> There is extreme resistance in the developer world to any kind of >>>>>>> prescribed tooling, so tightly coupling to any tool has a high cost, >>>>>>> and we >>>>>>> don't need to pay that cost if Bower is just one of the possible ways >>>>>>> to >>>>>>> get stuff. >>>>>>> >>>>>>> For example, I'm on record against using 'bower_components' as a >>>>>>> folder name (all our projects use a .bowerrc to reset that name) >>>>>>> because >>>>>>> our components can be installed any number of ways, Bower is simply not >>>>>>> a >>>>>>> requirement. >>>>>>> >>>>>>> Bower is awesome, I'm not knocking it. But IMO part of it's >>>>>>> awesomeness is the flexibility it offers. The ability to rename the >>>>>>> components folder and the ability to use Org/Repo package identifiers >>>>>>> are >>>>>>> really the primary reasons I chose this tool over NPM. >>>>>>> >>>>>>> Scott >>>>>>> >>>>>>> >>>>>>> On Tue, Feb 25, 2014 at 7:42 PM, Rob Dodson >>>>>>> <[email protected]<javascript:> >>>>>>> > wrote: >>>>>>> >>>>>>>> I'm not sure I agree with the sentiment in this case only because >>>>>>>> I'm worried the cons might outweigh the pros. >>>>>>>> >>>>>>>> Here are all the cons I can think of: >>>>>>>> >>>>>>>> You can end up with multiple directories for the same stuff. I >>>>>>>> think this is actually a big enough problem on its own to outweigh >>>>>>>> everything else. There are many people who are not bower savvy who >>>>>>>> will >>>>>>>> have a tough time debugging issues with a polymer and polymer-polymer >>>>>>>> directory floating around in their bower_components dir. I'm really >>>>>>>> worried >>>>>>>> about component authors mixing Owner/Repo and registry named >>>>>>>> dependencies... >>>>>>>> >>>>>>>> Many people use bower's command line search tool (myself included) >>>>>>>> which only looks at packages in the registry. If we don't register our >>>>>>>> packages we're removing that avenue. Technically some of our packages >>>>>>>> are >>>>>>>> registered but not all of them, which leads to the next point... >>>>>>>> >>>>>>>> If we don't register our packages (polymer-ajax, for example) it >>>>>>>> means someone else can squat on the name. Which is a bit of a bummer. >>>>>>>> And >>>>>>>> folks might install the wrong component. >>>>>>>> >>>>>>>> It feels "un-bower" like to force people to use Owner/Repo syntax. >>>>>>>> Polymer is the only project I know of which goes this route. Most >>>>>>>> libraries >>>>>>>> that know about bower and include a bower.json have a name in the >>>>>>>> registry >>>>>>>> that they encourage people to use. >>>>>>>> >>>>>>>> >>>>>>>> The pros I can think of: >>>>>>>> >>>>>>>> It makes it easier to manage all of your components when you don't >>>>>>>> have to deal with registering them. This is especially tough on a >>>>>>>> project >>>>>>>> like polymer where components have so many interdependencies. >>>>>>>> >>>>>>>> You're not too tied to the bower name/brand/methodology. You don't >>>>>>>> want people thinking that bower "owns" these components, in some >>>>>>>> fashion. >>>>>>>> >>>>>>>> You don't have to fight over a registry name. If someone had >>>>>>>> already registered polymer-ajax it wouldn't be a big deal to keep >>>>>>>> using >>>>>>>> Owner/Repo. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Ultimately we're telling users two different ways to do it in our >>>>>>>> docs which has to be confusing for anyone new to bower. Above all else >>>>>>>> we >>>>>>>> should decide which direction to go with and use it everywhere. >>>>>>>> >>>>>>>> - Rob >>>>>>>> >>>>>>>> >>>>>>>> On Tue, Feb 25, 2014 at 7:02 PM, Scott Miles >>>>>>>> <[email protected]<javascript:> >>>>>>>> > wrote: >>>>>>>> >>>>>>>>> I'm not a fan of central registries. I've advocated using >>>>>>>>> `Polymer/<element>` syntax since we embraced Bower, so that's my >>>>>>>>> $0.02. >>>>>>>>> >>>>>>>>> Scott >>>>>>>>> >>>>>>>>> >>>>>>>>> On Tue, Feb 25, 2014 at 3:28 PM, Marcin Warpechowski < >>>>>>>>> [email protected] <javascript:>> wrote: >>>>>>>>> >>>>>>>>>> In my projects I have experienced some problems (version >>>>>>>>>> conflicts) when using "polymer", since then I am using >>>>>>>>>> "Polymer/polymer". I >>>>>>>>>> am sure not everyone understands bower so deep to understand the >>>>>>>>>> implications, so I think it would be good to do it consistently. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Tuesday, February 25, 2014 10:42:28 PM UTC+1, Rob Dodson wrote: >>>>>>>>>>> >>>>>>>>>>> I noticed there are some polymer packages registered in the >>>>>>>>>>> bower registry. >>>>>>>>>>> >>>>>>>>>>> polymer (links to components/polymer) >>>>>>>>>>> polymer-platform >>>>>>>>>>> polymer-elements >>>>>>>>>>> polymer-ui-elements >>>>>>>>>>> polymer-polymer (links to Polymer/polymer) >>>>>>>>>>> >>>>>>>>>>> In the polymer docs, we sometimes tell people to install from a >>>>>>>>>>> package >>>>>>>>>>> >>>>>>>>>>> $ bower install polymer >>>>>>>>>>> >>>>>>>>>>> and we sometimes tell them to install from the repo >>>>>>>>>>> >>>>>>>>>>> $ bower install Polymer/polymer-elements >>>>>>>>>>> >>>>>>>>>>> I'm wondering if there might be an incompatibility situation. >>>>>>>>>>> For example, if a component author adds polymer-polymer to their >>>>>>>>>>> bower.json file, then bower is going to create a folder called >>>>>>>>>>> "polymer-polymer" in the bower_components dir. If another author >>>>>>>>>>> depends on >>>>>>>>>>> "polymer" then the bower_components dir will now contain >>>>>>>>>>> directories for >>>>>>>>>>> both polymer and polymer-polymer. So you might end up with elements >>>>>>>>>>> importing the same libraries from different locations. >>>>>>>>>>> >>>>>>>>>>> I'm wondering if we should have one consistent way of doing (and >>>>>>>>>>> documenting) everything? >>>>>>>>>>> >>>>>>>>>> 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] <javascript:>. >>>>>>>>>> To view this discussion on the web visit >>>>>>>>>> https://groups.google.com/d/msgid/polymer-dev/1154107e-afb1-4a7f-85ca-f405fb1725d4%40googlegroups.com >>>>>>>>>> . >>>>>>>>>> >>>>>>>>>> For more options, visit https://groups.google.com/groups/opt_out. >>>>>>>>>> >>>>>>>>> >>>>>>>>> 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] <javascript:>. >>>>>>>>> To view this discussion on the web visit >>>>>>>>> https://groups.google.com/d/msgid/polymer-dev/CAHbmOLaCe-wcFFWa_Sxayq4rNsAeGWPDfn1MOm-%2B%2BS%2By6FLyaQ%40mail.gmail.com >>>>>>>>> . >>>>>>>>> >>>>>>>>> For more options, visit https://groups.google.com/groups/opt_out. >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> 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] <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/polymer-dev/CAJj5OwBL-mbdgZ954eGFtPcqvva8H1tfKfEGnx9t284NJx8hBQ%40mail.gmail.com >> . >> >> For more options, visit https://groups.google.com/groups/opt_out. >> > > 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/6f4c7376-c4df-49d8-a5e9-e08d7e6b9081%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
