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?

This seems like a sticky issue, and maybe npm and component are incompatible, but any component with other dependencies is nearly impossible to consume as an npm module.

This is because we have, say component/each within component/collection. Well if we wanted to make component/collection a node module, we'd need require('each') to be require('each-component')

This makes it very hard to take advantage of creating modules that work on both client-side and server-side, unless they're trivial (no dep) components.

Anyone who stumbles onto a component repo, unless they already know what component is, may have a hard time figuring out what this 'component install' thing is and where to get it from. It's made especially bad since the term 'component' is particularly ungoogleable.

Even if the module author manually includes a link, where should they link to? component/component repo? Wiki? FAQ? Original blog post? Later, I assume component.io will be the go to, but even then, people may still link back to the wiki, or worst case (which is also currently the most common case)… not link back at all.

A good way to get some consistency here would be to add such a link to the auto-generated Readme template… which you could make cool by using an image. Which you could make even cooler if it was a dynamic image, e.g.:

This live example displays the current total number of components (updated regularly). Could look sexier or display different info, whatever, just an example. Hacked together code for the image generation here.

At the moment it just links back to the wiki, but I think a smart move would be to not link to the target image/landing page directly, instead embed dynamic urls:

component.io/:repo/:user/component.png component.io/refer/:repo/:user

Initially, every repo and link might go to the same target, but later you could centrally and retroactively control the imagery and link target on the readmes of the entire component swarm, without having to go update each repo. That's kinda cool.

Anyway, the core idea is: embed something in the readme template so any components that use component(1) create will refer traffic back to some place where people can find out the what/why/how of component.

I'm experimenting with the newest component (master) and keep getting this error: Error: timeout of 5000ms exceeded.

Here's the relevant DEBUG=* output:

  component-resolver:semver resolving semver component/notification@* +0ms
  remotes:local resolving local remote +569ms
  remotes:local checking folder: /home/vagrant/go/src/github.com/treetopllc/nobleweb/components/component/notification +1ms
  remotes:github GET "https://raw.github.com/component/notification/master/component.json" +0ms
  cogent timeout exceeded for GET https://raw.github.com/component/notification/master/component.json +0ms
  cogent retrying GET https://raw.github.com/component/notification/master/component.json +2ms
  cogent timeout exceeded for GET https://raw.github.com/component/notification/master/component.json +5s
  cogent retrying GET https://raw.github.com/component/notification/master/component.json +2ms
  cogent timeout exceeded for GET https://raw.github.com/component/notification/master/component.json +5s
  cogent retrying GET https://raw.github.com/component/notification/master/component.json +1ms
  cogent timeout exceeded for GET https://raw.github.com/component/notification/master/component.json +5s
  cogent received error "timeout of 5000ms exceeded." with "https://raw.github.com/component/notification/master/component.json" +0ms

       error : Error: timeout of 5000ms exceeded.

It's basically the first remote it comes across, all my locals seem to resolve just fine.

(fwiw, that URL opens up fine in a browser)

I find your components useful. I use browserify & npm for writing client-side code.

I'm left with either rewriting their functionality or publishing them to npm.

If you don't dual publish to npm I will.

I know this has been brought up in the past a little bit, but I'd like to bring it up again since it's been a while and things have gotten more fleshed out.

One thing that feels frustrating when working with component is that while .js and .css are handled natively, .html isn't even though it's the third of the three major pieces. Having to use component-convert or having to include an external plugin just for .html support are both burdens that ideally the build tool would remove in my opinion.

I think it would be nice to see .html become a natively supported filetype, because it's natively supported on the web, and would make developing components with templates a painless for the dev without being too magic-y.

Note: I'm only talking about .html. Other templates like .hbs or .jade should definitely not be natively supported since they aren't native on the web.

An argument against that I saw was the a .html might not be just straight HTML, but instead another templating language. My opinion there is that if you aren't writing HTML you shouldn't be using the HTML extension...

The other question is often how to do the transformation: does template.html become template.js? Because that could clobber other files. I think the simple solution here (and clearer too) is for it to become template.html.js so that when you're requiring it from your Javascript it's very clear what's going on, and you won't clobber your other files:

var template = require('./index.html');

I think this should be made the standard too, eg. I never should have made component-jade remove the .jade extension.

Which would require the template you defined in your component.json, so we can finally really cleanly, and easily handle all three native types:

"scripts": [
  "index.js"
],
"styles": [
  "index.css"
],
"templates": [
  "index.html"
]

And shit just works:

var domify = require('domify')
  , reactive = require('reactive')
  , template = require('./index.html');

module.exports = View;

function View (model) {
  this.model = model;
  this.el = domify(template)[0];
  this.reactive = reactive(this.el, model, this);
}

I'm running into this more as I develop UI components and not just pure Javascript things. What do you guys think?

hey @jonathanong @visionmedia and everyone in @component/owners and other people watching, would love some feedback on this...

i'm super excited to see some so much activity from jon on component (and component.io and docs!) and seems like we're getting close to 1.0.0 which is sick

i wanted to get this kind of discussion going while 1.0.0 is still not finalized before its too late to make changes like this

i've just pushed up a branch called idea which you can check out. i had some ideas for how we might potentially be able to structure the core library while refactoring around a component-oriented, and functional approach. this is still in the early stages of the idea, but please check out that branch and let me know your thoughts.

specifically check out:

• the Component constructor as the core API that users interact with
• the install logic
• the component-install logic

a couple caveats:

• i deleted a bunch of the code, not because i think those things shouldnt be in core, but just so i could get a sense for what i had successfully reproduced and what i hadn't yet. aka just so i could concentrate, so don't worry if you're thinking "where's component search?" or similar
• i built the installer with a simpler way to resolve semver. to reduce complexity and since CSS doesn't have a good way to version itself, i went with the ruby/python/whatever approach where if there are conflicts, the whole thing fails. i think with CSS not having a way for us to version things this is a logical way to approach the first attempt, since it also means we get to drastically cut the complexity of having to manage multiple builds for a given component
• this is still a work in progress, lots of features from spec and such aren't implemented. that isn't a decision not to implement most of them. there are a few however (like globbing) that i've eliminated from the current prototype on purpose to reduce complexity, and they could potentially be added in later, but for now i saw good simplicity gains from keeping them out on purpose
• some of the async-ness of install can still be simplified, doing that as i go along. of course some of the install code is just complex because the process is complex by nature
• build is still very much a work in progress, seeing as it doesn't do anything :) starting into that right now
• i haven't added in locals support yet at all, but will soon. that will surely break some of the abstractions and require rethinking some
• some of the logic like remote would be in a separate repo. i signified this by anything that is in a folder inside of ./lib, so that means we'd have component/logger component/spec etc.

what i was looking to do was try to reduce complexity wherever possible, sometimes that means cutting features, or just nice-to-haves, so that we can arrive at a solid core to build on top of. there still needs to be more refactoring

i would love input on what you all think, if this is a valid-looking direction. and if anyone wants to hack away with me i'm going to pursue the idea some more over the next two days

@clintwood @jasonkuhrt @netpoetica @trevorgerhardt @jonathanong

what do you think to release 1.0.0?

So we can do a list what we should fix for this version, for instance I saw a note here: https://github.com/componentjs/component/blob/master/History.md#100-rc4--2014-04-04

Component 1.0.0 is now feature complete. Please help debug and open an issues you may have with this release! 1.0.0 will not be released until http://component.io is updated.

TODO before release

• [x] update all internal components (builder2.js, etc.)
  • [x] builder2.js
  • [x] console.js
  • [x] resolver.js
• [x] add tags for all component/ repos to fix * dependency / pin version this become obsolete
• [x] merge https://github.com/componentjs/component/pull/596
• [x] custom remotes
• [x] check ".remotes is currently in flux and is pretty much broken. Don't set a .remotes array in your component.json for now!" can it be removed?
• [x] http://component.io #587, fix broken website url
• [x] --standalone arg in combination with a component.json standalone property #24
• [x] cannot require below the root #22
• [ ] test all CLI tools with args component CLI API
• [x] docs
  • [x] refactor docs and links, split into docs for 0.x and 1.0
  • [x] check the spec spec - is it in sync with the implementation?
  • [x] update some links,etc. in the docs, like for github: remove raw.github.com
  • [x] show how to use the github token, instead of username and password
• [x] #573 don't exit watcher when syntax errors occur in scripts
• [x] https://github.com/componentjs/builder2.js/issues/29 locals ordering sometimes wrong
• [x] https://github.com/componentjs/builder2.js/issues/82
• [x] https://github.com/componentjs/builder2.js/issues/84

as discussed in #components we'll soon have to implement the semver portion and adding warning for incompatibilities. There are a few ways we could approach this, the most correct way being addition requests to fetch the tags per component, which adds some annoying overhead that we may end up having to cache to keep component-install(1) nice and speedy. Alternatively we optimistically fetch all the versions as demanded, then apply semver checks and ensure everything is within range.

If there's a conflict we could either warn, or actually include the duplicates though this would complicate the builder and many other aspects of the system. My opinion is that a major version change is an API failure, they will happen, however with components being small we should have relatively few of these cases, so going with no duplicates should be reasonable

Pull-request for issue #286

This allows you to set paths in the remote section of the manifest for custom URL paths:

{
   "remotes": {
      "https://privateserver": "/{name}/blobs/raw/{version}/{file}"
   }
}

While still letting you use the array list of remotes as before. If you use an array of remotes it will use the default 'template' of /{name}/{version}/{file} — aka the github-style.

Primary use case for this is for git servers that don't use the github URLs. This means you could use Component with Bitbucket (I think) and Gitorious, which is great for setting up an internal registry of components.

 error : Error: no remote found for dependency "es-shims/[email protected]".

I've started getting things like this for components that use 'v' prefixes on their tags in github. I saw this first with my branch of linkedin's dustjs branch. I solved that by adding a non-v-prefixed tag and then hard-coding the tag in component.json.

However, it looks like es5-shim actually updated their component.json: https://github.com/es-shims/es5-shim/commit/29634c271a44889770b73abc2c49bba29e47b960

I've spent a couple hours trying to track down what would be causing this, but frankly the code is brutal to look through after it's built and I'm just not able to figure out what's happening.

@componentjs/owners I think it's obvious that component is not maintained anymore. We should put a note in the readme of this repo, not just because it's not maintained, but also component has several issues:

• endpoint only for GitHub and BitBucket
  • rate limit, even if you use an auth token example
• maintain an extra file: component.json
  • need to fork a module when it doesn’t exist
• plugins can only be used via the API
• annoying to update remote dependencies in all locals example
• it’s not maintained anymore, see contributors

@jonathanong wrote a post after he rewrote component: http://www.jongleberry.com/the-future-of-component.html After nearly a year he wrote this: http://www.jongleberry.com/the-story-of-normalize.html

In particular, the more I learn about Webpack, the more amazed I am and its features, especially hot reloading.

We're using component at our company and realize in the last week a drop-in replacement for webpack, it's working fine. The biggest work was to fix all the component repositories where a package.json was configured wrong or didn't exist.

I think it's really annoying to touch all the locals if you want to upgrade a dependency which is used my almost all of your locals, here is an real world (open source) example: https://github.com/DemocracyOS/app/issues/927

at our company we have the same issue

@jonathanong was it by design to prohibit defining remote dependencies at the root level and use them on local level?

I'm :+1: for changing this, actually like https://github.com/componentjs/component/pull/337 but for remotes

Hi. I am getting problems fail to install in particular computer. but other one (in same local network, same component version) is success. furthermore, when after "npm install -g component" yesterday, it is working good. I don't know why. and how to fix it? help me plz.

C:\>component install lodash/lodash

  remotes:local checking local components at C:\components +0ms
  component-resolver remote not set - defaulting to remotes's defaults +4ms
  component-resolver:locals resolving local at "C:\" +4ms
  component-resolver resolving "root" +1ms
  component-resolver remaining dependencies: 1 +4ms
  component-resolver remaining semver: 0 +1ms
  component-resolver finished resolving locals +1ms
  component-resolver finished resolving dependencies (1) +1ms
  component-resolver:semver resolving semver lodash/lodash@* +1ms
  remotes:local checking folder: C:\components\lodash\lodash +2ms
  remotes:github GET "https://api.github.com/repos/lodash/lodash/tags" +3ms
  cogent options: { protocol: 'https:',
  slashes: true,
  auth:  // AUTH TOKEN REMOVE... 
  host: 'api.github.com',
  port: null,
  hostname: 'api.github.com',
  hash: null,
  search: null,
  query: null,
  pathname: '/repos/lodash/lodash/tags',
  path: '/repos/lodash/lodash/tags',
  href: 'https://api.github.com/repos/lodash/lodash/tags',
  headers:
   { 'accept-encoding': 'gzip',
     'user-agent': 'https://github.com/cojs/cogent',
     accept: 'application/json' },
  method: 'GET' } +4ms
  remotes:bitbucket GET "https://api.bitbucket.org/1.0/repositories/lodash/lodash/tags" +3s
  cogent options: { protocol: 'https:',
  slashes: true,
  auth: null,
  host: 'api.bitbucket.org',
  port: null,
  hostname: 'api.bitbucket.org',
  hash: null,
  search: null,
  query: null,
  pathname: '/1.0/repositories/lodash/lodash/tags',
  path: '/1.0/repositories/lodash/lodash/tags',
  href: 'https://api.bitbucket.org/1.0/repositories/lodash/lodash/tags',
  headers:
   { 'accept-encoding': 'gzip',
     'user-agent': 'https://github.com/cojs/cogent',
     accept: 'application/json' },
  method: 'GET' } +5ms
  component-consoler Error: no remote found for dependency "lodash/lodash".
    at Resolver.<anonymous> (C:\Users\js\AppData\Roaming\npm\node_modules\compon
ent\node_modules\component-resolver\build\semver.js:565:13)
    at Generator.invoke (C:\Users\js\AppData\Roaming\npm\node_modules\component\
node_modules\component-resolver\build\index.js:141:31)
    at Generator.invoke (C:\Users\js\AppData\Roaming\npm\node_modules\component\
node_modules\component-resolver\build\index.js:79:50)
    at next (C:\Users\js\AppData\Roaming\npm\node_modules\component\node_modules
\co\index.js:74:21)
    at C:\Users\js\AppData\Roaming\npm\node_modules\component\node_modules\co\in
dex.js:93:18
    at Gunzip.onEnd (C:\Users\js\AppData\Roaming\npm\node_modules\component\node
_modules\component-remotes\node_modules\cogent\node_modules\raw-body\index.js:14
9:7)
    at Gunzip.g (events.js:199:16)
    at Gunzip.emit (events.js:129:20)
    at _stream_readable.js:908:16
    at process._tickCallback (node.js:355:11) +2s

       fatal : no remote found for dependency "lodash/lodash".

  remotes:github:api used 1 +12ms

component-install[.cmd] is auto generated an I cannot seem to be able to get component install to be called from my module via npm install with the --harmony flag set in node.js via an exec.

https://github.com/UKDemocracyOS/app/blob/development/bin/dos-install#L56

as this is calling component via npm and 'node_modules.bin\component-install' I cannot seem to get the contained component-install to run in harmony mode.

Something very wrong with some component within componentjs fold :-

fatal : Error downloading "github//component/[email protected]". Got status code "404"

This is a new error occurring on machines that previously worked with the https://github.com/UKDemocracyOS/app and parent project https://github.com/DemocracyOS/app the project has been fine for days and many complete from scratch retests. using a --timeout of 480000.

Hi,

I am getting problems finding modules/packages.

I am working in parallel on Linux and Windows.

I have done a :-

npm install -g component

And am having problems with 'visionmedia/debug' on Windows but not on Linux. But I am having problems on Linux on the top level directory install.

component install visionmedia/debug

is working fine in my 'lib/debug' directory of https://github.com/UKDemocracyOS/app on Linux But on Windows I am getting :-

fatal : no remote found for dependency "mediavision/debug".

https://github.com/visionmedia/debug exists.

My Linux component.json files are here and I will attach the Windows ones which should be the same.

app/lib/debug/component.json { "name": "debug", "dependencies": { "visionmedia/debug": "^2.1.3" }, "locals": [ "config" ], "scripts": [ "index.js" ], "main": "index.js" }

app/component.json

{ "name": "democracyos", "version": "0.14.0", "description": "An online space for deliberation and voting on political proposals. The software aims to stimulate better arguments and come to better rulings.", "paths": [ "lib" ], "locals": [ "boot" ] }

app/lib/boot/component.json { "name": "boot", "description": "bootstrap component", "dependencies": { "visionmedia/page.js": "1.3.7", "component/t": "1.0.0", "component/bus": "^0.0.2", "DemocracyOS/timeago": "master", "code42day/ga": "1.1.0", "slifszyc/user-agent": "0.0.9" }, "locals": [ "config", "body-classes", "content-lock", "homepage", "proposal", "law", "signin", "signup", "forgot", "settings", "translations", "flaticons", "admin", "header", "logout", "help", "404", "browser-update", "debug" ], "scripts": [ "boot.js" ], "styles": [ "boot.styl", "boot-responsive.styl" ], "images": [ "images/check.png", "images/favicon.ico", "images/logo.png" ], "main": "boot.js" }