componentjs / component Goto Github PK

for example component search popover --open would open all the "popover" repo docs in your default browser so you can compare

another G suggestion:

dependencies: ['component/tip', 'component/popover#0.5.0']

another nice thing about this is that "bundled" deps would be an array anyway

some components will have static resources like images etc., linked to in css files eg.

what i've done to solve this is:

• write absolute paths, like url(/image.jpg)
• copy those resources to build/<component>/ in the build step
• add the path prefixes with regexes

I like the way that goes, as long as resources are only referenced to in css.

to similar solutions, surely lots of people will be wondering what the differences / avantages are

I try to get some images, referenced in the css, into my build.
Preferably with keeping the images subfolder ;)

{
  "name": "jquery-mobile",
  "repo": "solutionio/jquery-mobile",
  "description": "Jquery Mobile in component",
  "version": "0.0.1",
  "keywords": [],
  "dependencies": {
    "component/jquery": "*"
  },
  "scripts": [
    "compiled/jquery.mobile.js"
  ],
  "styles": [
    "compiled/jquery.mobile.css"
  ],
  "files": [
    "compiled/images/ajax-loader.gif",
    "compiled/images/icons-18-black.png",
    "compiled/images/icons-36-black.png",
    "compiled/images/icons-18-white.png",
    "compiled/images/icons-36-white.png"
  ]
}

yori:jquery-mobile sebastian$ component build -v

       write : build/build.js
       write : build/build.css
          js : 531kb
         css : 105kb
    duration : 29ms

add to superagent or remove superagent and just pipe to disk

blog post or screen cast detailing how we should be creating smaller things, as to not force "frameworks" on people that do not wish to use them, in the process unifying the javascript community rather than segmenting it. Detail how jquery-style APIs are a great example of what not to do, and that if you must use jQuery, underscore, or similar for now, that they should merely be implementation details and should not be visible in your API.

when the config is present HEAD those urls to lookup, otherwise just assume they're available on GH

https://github.com/visionmedia/rework

the idea here is that when you define a component, your CSS uses non-vendor-prefixed styles, freeing the burden from people developing components, as well as allowing the consumer to decide which vendors they support, thus potentially smaller builds.

the one thing im concerned about here is that this would implicitly force others developing alternatives to these node/javascript tools to write something similar to rework... for that reason it might be better not to do this, though I really never want to look at vendor CSS again, nor do I want people sending pull-requests to ever component out there for stupid IE crap when it's not really their concern.

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.

component-create produces a Makefile with "undefined.css" in the build: step.

Let me know if you want me to submit a pull request.

Cheers,
Colin

this is just an idea... and very low priority, but it might be interesting to have something like component localize to fetch all (or specified?) components and store them locally for offline dev

so we have one list to index for search

here is the output:

 11:59 ~/temp/test -> component -V
1.0.0
 11:55 ~/temp/test -> node -v
v0.6.10
 11:55 ~/temp/test -> component-create  .
name: test
description: test
does this component have js? no
does this component have css? no
does this component have html? yes

      create : .

/usr/local/lib/node_modules/component/bin/component-create:78
    conf.scripts.push('template.js');
                 ^
TypeError: Cannot call method 'push' of undefined
    at /usr/local/lib/node_modules/component/bin/component-create:78:18
    at next (/usr/local/lib/node_modules/component/node_modules/commander/lib/commander.js:825:24)
    at /usr/local/lib/node_modules/component/node_modules/commander/lib/commander.js:828:9
    at ReadStream.<anonymous> (/usr/local/lib/node_modules/component/node_modules/commander/lib/commander.js:761:5)
    at ReadStream.g (events.js:156:14)
    at ReadStream.emit (events.js:67:17)
    at TTY.onread (net.js:342:31)

Hello,

It would be nice to have at least support for some other registry. For example bitbucket.org.
This way for sure the component format will be future-proof. Not all use GitHub.

Regards,
Godfryd

for example with calendar as a dev dep, none of its deps are installed

When the scripts array looks like this:

"scripts": [ "./index.js" ]

component adds this line to the build:

require.register("formwatcher-bonzo/./index.js", etc...

which causes it to fail locating the file.

So I suggest that the files in the scripts array should be stripped of ./

Is there any way to install local components just like npm?

  $ component install ~/me/path/to/my-component

doesn't work... as it tries to fetch from github…

whereas npm can handle this well.

  $ npm install ~/me/path/to/lib

Running any of the component commands on windows leads to the message:

CreateProcessW: The system cannot find the file specified.

Can we make the readme files default to the same ones that github produces if you add a description and tell github to generate you a readme? Also can we detect that the readme is as per the github default and then use that as the default description?

Please add a -v parameter giving more information about what happens

so that you may choose say ./dialog.js over ./index.js

I want to build a component replacement for jEditable. I want to know how I would go about supporting plugins for different sorts of editors. If this was node, I'd be letting people npm install plugins then give me the name of the plugins so I could require it:

function usePlugin(name) {
  var plugin = require(name);
  //do things with plugins
}

I want to specify the plugin by name because I want to choose the plugin in the html, not in the code. However the correct aliases won't exist for me to do this? Can I reference them using their full paths (e.g. component-type), will that solve my problem?

some form of this may be useful. for example if you have installed components in ./components, and private app-specific stuff in ./lib we'll need a way to grab this for the build

package.json pros:

• people are already using it (thus more likely to augment to support components)
• no duplicated keywords / description etc
• silly to add a package.json for dev deps (mocha etc)

component.json pros:

• discoverability (programmatically and visually)
• majority of components will be client-only (dom / ui related things, css, etc)
• no need to prefix or use strange keys in package.json (clientDependencies ?)
• "name" needs to reflect "username/project" not just "project"
• less ambiguous

not sure what syntax npm uses for this, does it even allow this?

{
  "dependencies": {
    "/some/component/path": true
  }
}

to show that you can use components just like AMD etc... it doesn't have to be a barrier for development

some components will have text strings in their html and text needs to be translatable. what i've done so far is

• wrap strings to be translated with curly brackets: {{mystring}}
• let my build process exchange that with calls to the function _
• let my build process add a require to the translation function inside each template, like var _ = require('translate').translate (with a bind)

however that feels cumbersome and depends on a certain i18n-library.
exchanging those strings with dom traversal is slow, however then you could pass an object with all translations to the component's constructor.

ideas?

I'm kinda stuck there... Unit testing a component with mocha is pretty easy. But as soon as there are dependencies involved it gets kinda messy. I can't just install the other components with npm, and I can't include the build.js in mocha.

So, am I forced to write the tests in the browser and include the build?

EDIT: And I'm aware that unit testing should happen without the other modules, but I can't stub them because my component already fails when trying to require another one.

I tried to register a component that I had not yet pushed a component.json

yori:backbone sebastian$ component register solutionio/backbone

events.js:66
        throw arguments[1]; // Unhandled 'error' event
                       ^
Error: connect ECONNREFUSED
    at errnoException (net.js:768:11)
    at Object.afterConnect [as oncomplete] (net.js:759:19)

for meeee to debug, output to /tmp/component.log

otherwise we'll run into collisions.. right now it's up to whatever you put as "name", but if two deps have "foo/inherit" and "component/inherit" with different APIs then we'll have issues. This means you'll need to do var inherit = require('component/inherit'), kinda sucks but it's not the end of the world.

Also for people who see this and think "ewwww", it's not that bad, otherwise you end up with things like this in npm:

• progress
• progress2
• progress-bar
• progressify
• progress-component

to facilitate weirder things like fonts, to make sure we still specify them as part of the package, but as arbitrary blobs. This is necessary because otherwise we need to download a tarball or use a git clone which is quite slow

Make is not cross platform, using Make for building components will lead a lot of people to assume you can't build components on Windows.

for ex right now if you have 5 things depending on emitter it'll try and fetch emitter 5 times, so this can be much faster. when we take versions into account this is a bit trickier but we need to warn on conflicting semver versions anyway

annoying to navigate there manually all the time. component list? component wiki?

this is the one major downside of using GH. I was hoping that their search API would allow me to discover projects using a ./component.json file, but in the meantime we might have to do something else like keep a component/search.json repo or something

Using this tool https://github.com/component/wiki, we would periodically fetch component.json files and warn the users if they're missing required properties etc

related: ladjs/superagent#96 (comment)

to style the cli output

i have a structure like this

index.html
/lib/app.js

to use app.js i require
var app = require('pomodoro-watch/lib/app');

which is ok, i referenced it as "lib/app.js" in the scripts array

But when I make use of for example jquery in app.js, i have to use

var jQuery = require('../../component-jquery');

would a single ../ not be more logical and adding to it, it is anyway registered as component-jquery/index.js in the build.js file so a

var jQuery = require('component-jquery');

would be very convenient to use that from wherever i am .. especially for stuff that is in the components dir

to include devDependencies in the build

Like #14, but for components that are in private repositories on GitHub. The current implementation does a fetch to https://raw.github.com/' + this.name + '/' + this.version + '/' + file, but that isn't available (at least without a username and password) for private projects.

I just watched your screencast and I have a much better idea of where you want to go with components. One thing that's unclear to me is how to use components across pages on a site.

The current approach is great for single-page web apps, but it seems a bit verbose when you have multiple pages (component.json and separate components/ directory for every page).

Any thoughts on this? Maybe I'm missing something?

Thanks!
Matt