component.json

[kc-dot-io]

At Retsly - ( www | github | recently acquired ) - we have invested a ton of time into Backbone and have realized many of the same pains that Ampersand appears to solve. It seems like a natural choice for us to begin to transition most of our important projects over and we're really excited about this possibility.

That said however, we have a bit of hesitation around the perception that the Ampersand community only supports npm + browserify. Not that these aren't a great solution... They are, but we've invested a lot of time into Component and are keen to continue to using it in until at least a time when that the Duo project get's more traction or a crystal clear winner emerges on the front end (we'd pick npm + browserify over bower any day so don't hate plz).

So, before we move over to Ampersand I'd like to candidly ask what the Ampersand team thinks about supporting multiple package manager / builders in parallel? As far as I can tell this could be as simple as adding a component.json to each module while continuing to use the github releases feature you already use.

We have a team of 10+ developers over here who'd be more then happy to contribute Ampersand modules as well as the ongoing support of Component (and Duo as it evolves) integrations so my hope would be that this additional integration point wouldn't require a lot of overhead for the founding Ampersand team.

In addition, adding support for other package managers should allow you to get Ampersand into the hands of as many Backbone converts as possible because realistically they may not be in a position to adopt npm + browserify if they have existing code bases or have a different opinion on how they would like to install / build these ampersand modules.

Side note - We're in Vancouver Canada and travel to Seattle a lot as our parent corp is there, so perhaps there also opportunities to cross pollenate beer and js meetups with the Richland crew someday. Booyah.

Anyway, Ampersand looks great and thanks in advance for your reactions!

[wraithgar]

Personally, this feels like exactly the kind of thing that one hopes for when other shops adopt a framework. If there is going to be someone or someones contributing/updating these (or helping us to know what tweaks are needed when we tick versions, which appear to be small) this seems like a great fit. Afaik it's just adding the file, right? Component is commonjs still? No need to suddenly have pre-browserified copies sitting in the repo or anything?

[latentflip]

Yeah, if we can make this work with component without crazy effort and other people want to help and use ampersand... big +1 from me.

[kamilogorek]

+1 especially after your great introduction :)

On Wednesday, November 5, 2014, Philip Roberts notifications@github.com wrote:

Yeah, if we can make this work with component without crazy effort and other people want to help and use ampersand... big +1 from me.

— Reply to this email directly or view it on GitHub https://github.com/AmpersandJS/ampersand/issues/69#issuecomment-61837695 .

Kamil Ogórek

http://kamilogorek.pl kamil.ogorek@gmail.com @kamilogorek

[kc-dot-io]

Awesome! Glad to hear it and nice to meet you guys.

So yeah @wraithgar, Component and Duo both are common JS and support installing / updating directly from Github's releases API. They are basically trying to solve both of what npm + browserify do in one tool, they are very similar. Component requires a component.json manifest to figure out what to build which is basically the same as package.json (small duplication foot print, update semver when you publish, dependencies when you install them) but Duo plans to abolish the concept of a manifest and parse the actual code looking for require statements to determine the manifest then build through any of the 3 dominant build systems. Certainly an interesting idea, so we're watching it closely. Component also has a really nice approach for managing other assets like css, fonts, iconography and general images within each component and that is important to us because we have some folks who are very focused on user experience and they need a seat at the code table too.

The only gotcha that I can possibly foresee is that you guys tend to use the Github suggested v1.0.0 tagging / release style and I think in component land its a bit more common to drop the the v to ensure that you get proper semver support (which is hugely important as you guys already know). I'll test this caveat out today and see if component can parse int the existing tags to resolve semver properly. I also want to do a bit of due diligence around your dependencies and if component can support them as well, as that would be a blocker on adding this.

I'll report back with findings or a PR.

[wraithgar]

The v1.0.0 style is what npm version uses and I think we're pretty set on using that to tick versions.

[lukekarrys]

I'm also a +1, and according to the component guides, it is preferred to drop the v but will still work with it:

From the publishing guide

This isn't a big deal, but you should generally not prefix versions with a v. Component will handle both cases, but doing so requires an extra HTTP request.

[kc-dot-io]

Ok, so it's time to check back in with everyone.

We hacked around on this today and it appears the release tags aren't really too much of an issue but the bigger blocker is the lack of component.json files in the dependencies which was our main concern about this proposal.

It appears that ampersand alone (not including all the modules) directly has around 29 dependencies all of which would need to implement component.json into their repos for the component installer to resolve the dependency tree correctly. I'm starting to understand why Duo exists... Updating that many repo's seems like a tall order, so internally we're thinking it might be better to just jump on the npm + browserify train as we're liking what we see the more we look into it.

Unless anyone has any brilliant solutions for proficiently updating all these dependencies in a way that balances the value I am going to suggest that this was nothing more then a noble idea and close this issue because it is probably not worth the effort to update all these dependencies given Components decline in adoption since TJ dropped the mic and walked off stage.

Either way, good chatting with you guys, and we look forward publishing our first Ampersand module.

[kamilogorek]

Thanks for the insights @slajax! Have a good one.

[latentflip]

Is component.json required just in direct dependencies, or the whole way down the tree? If so that is indeed a lot of deps!

Philip Roberts &yet

On 6 Nov 2014, at 00:15, Kyle Campbell notifications@github.com wrote:

Ok, so it's time to check back in with everyone.

We hacked around on this today and it appears the release tags aren't really too much of an issue but the bigger blocker is the lack of component.json files in the dependencies which was our main concern about this proposal.

It appears that ampersand alone directly has around 29 dependencies all of which would need to implement component.json into their repos for the component installer to resolve the dependency tree correctly. I'm starting to understand why Duo exists... Updating that many repo's seems like a tall order, so internally we're thinking it might be better to just jump on the npm + browserify train as we're liking what we see the more we look into it.

Unless anyone has any brilliant solutions for proficiently updating all these dependencies in a way that balances the value I am going to suggest that this was nothing more then a noble idea and close this issue because it is probably not worth the effort to update all these dependencies given Components decline in adoption since TJ dropped the mic and walked off stage.

Either way, good chatting with you guys, and we look forward publishing our first Ampersand module.

— Reply to this email directly or view it on GitHub.