the future of component?

[timaschew]

It seems that contribution of some main contributors of component becomes low, due to some progress in the last months: https://github.com/component/component/graphs/contributors

• @visionmedia left node.js land
• people from segment.io use their own tool: duo
• @jonathanong started with normalize.io

// edit

• browserify seems to become more popular and works also for assets

we at our company use component heavily so it's very interesting for us how the future of component looks like and in which direction the development is going?

[timaschew]

@jonathanong @yields

duo uses Stat.mtime to only parse / build / fetch stuff that are not installed / built already, if that's what you meant ?

Yes, but how I explained, we need all manifest files to generate the make rules to build the assets (js, css), because we don't want to use component builder plugins (for coffee-script and stylus). So manifest files are mandatory for us.

I think it depends on the architecture of your app which tool (component or duo) fits better. I don't want to argue against duo, I think for the most architectures you can use it and it boosts your development. That's the reason why I created a tool to convert all your local components into duo compatible require paths.

https://github.com/timaschew/component2duo your feedback is welcome :)

[stephenmathieson]

@timaschew sounds like your build process is overly complex. why don't you want to use plugins?

coffee support could be as simple as:

var coffee = require('coffee-script')

module.exports = function (opts) {
  opts = opts || {};

  return function coffeePlugin(file, duo) {
    if ('coffee' != file.type) return;
    file.type = 'js';
    file.src = coffee.compile(file.src, opts);
  };
};

[yields]

gotta agree with @stephenmathieson here, i can't understand how manifests tie in with Makefiles or why would auto generating makefiles is better / easier than just using duo.

[timaschew]

we don't want to use it, because we don't want to tie too much with component, maybe we wanna switch to another tool in the future which doesn't support builder plugins like component, so the switch would be easier.

why would auto generating makefiles is better / easier than just using duo.

It's not only about easier, it's kind of architecture philosophy. With manifest files you have only one place per component with an overview of your dependencies, refactoring is done only in one file with a documented scheme. At the other site you have all your dependencies spread over your source files.

[ghost]

@stephenmathieson Hey, have you got your bitbucket code started or visible anywhere. I'll likely be taking some time to start something if not. I've had a read through the code to review the gh support at this point but ready to dig into this.

[stephenmathieson]

@fairwinds nope, not yet. There's basic custom provider support in ./duo/lib/parse.js, but that's all I've been able to convince @MatthewMueller to merge thus far :p

I think the eventual BB support will be something like:

var module = require('bitbucket.org/somebody/module@x.y.z:index.js')
// ... etc

I've got basic semver support with bb-resolve, but it needs a bit of work still.

I think the plan is to get Duo as stable as possible, then add features like BitBucket, etc.

edit: there's a PR for duo-package which adds support. I think it's conflicted at this point tho :/

[tj]

I can only speak for myself but I think keeping it GH only is a feature haha. When I see something that isn't on GH in Go-land I just don't use it, ~95% of Go software is on GH, the odd thing is on shitty Google code or Bitbucket. Maybe it could be supported but out of the box it's almost a negative instead of a positive IMO

[stephenmathieson]

@visionmedia i can only speak for myself too, but i use BB for business logic and GH for everything else. BitBucket offers free private repos, so it's hard to justify paying to host ~50 SLOC javascript components on GitHub.

[ghost]

@stephenmathieson Sadly, I am not able to access the duo-package repo just yet. Just don't want to repeat work someone may have already done. Agree with @stephenmathieson. Bitbucket may be behind on some capabilities but good value for private repos.

[kevva]

@fairwinds, you can download it from npm.

[tj]

@stephenmathieson ah yeah for private stuff that's cool

[clintwood]

@visionmedia, we run our own GH-like component server in-house for business logic (private) components (of which there are many) which we can't push to GH, so being limited to only GH is a non-starter for us.

@MatthewMueller, @yields, is there a way to add additional GH-like resolvers to Duo? I see duo-package uses gh-resolve and that looks pretty baked in... if that's that case would this be where it could be extended to use additional resolvers?

[jonathanong]

does anyone using bitbucket use mercurial? i wonder if that's something package managers should ever bother supporting

[termhare]

@jonathanong i think @stephenmathieson ways saying he uses bitbucket so he can have lots of free private repos. makes sense, especially if you want to follow component's super-modular conventions but don't have a few hundred dollars a month to spend on github

[jonathanong]

yeah i'm asking a different question. haha. bitbucket supports both git and mercurial repositories, but i don't know if people even use mercurial. if you only support git, then you can git ls remote bitbucket like it's github, just change the hostname

[termhare]

oh haha, sorry yeah i see now

[yields]

, is there a way to add additional GH-like resolvers to Duo? I see duo-package uses gh-resolve and that looks pretty baked in... if that's that case would this be where it could be extended to use additional resolvers?

i think we agreed on something like duo.provider(regexp, obj), obj has #auth, #resolve and #tarball, so should be pretty easy to add a provider i think.

[clintwood]

@yields, that would be great. I don't see it there now... :) so will hack away until it's OS...

[netpoetica]

does anyone using bitbucket use mercurial? i wonder if that's something package managers should ever bother supporting

I have seen Mercurial used by software devs much more than web devs, but Git is slowly taking over there as well. Only one web app company I worked for used Mercurial, but the lead dev who chose is was a C++ guy who did svn -> mercurial path. I imagine by now they have moved to git just for pure convenience of all web packages being on Github

[stephenmathieson]

@jonathanong I used hg on a project years ago just to test it out. never again though haha

[tj]

I guess what I should have said is public components should be on GH, otherwise it's just pure rage haha

[tj]

Oh and the cool thing is if it goes more Go-like then you can have many packages in a single repo no problem without any special exporting code. I have 33 Go packages in one repo right now for example, then if you need to break compat you just append -v2 or move it to its own repo

[stephenmathieson]

I guess what I should have said is public components should be on GH, otherwise it's just pure rage haha

agreed ;)

[jonathanong]

then if you need to break compat you just append -v2 or move it to its own repo

lol

[clintwood]

..., otherwise it's just pure rage haha

hahaha, lovely...

[timaschew]

closing due to https://github.com/componentjs/component/issues/601#issuecomment-56864116 and https://github.com/componentjs/component/pull/604

[timaschew]

related: https://github.com/componentjs/component/issues/639