Skip to content


Subversion checkout URL

You can clone with
Download ZIP


Fix require automatically #554

merged 1 commit into from

10 participants


No description provided.


The list keeps getting bigger :(


It would be nicer if this was the other way around. At least it would stay consistent with pre 1.0


@anthonyshort it'll be more difficult to use without aliases

@kazupon why would you use this?


becase, there are cases of require manually.
for example, application recieve data from server-side, when page is rendering.

require('boot')({ foo: 'bar'});

how do you deal with locals though since the builder rewrites them? i guess it isn't too hard to figure out since it mimics your project structure.

hmmm... i feel like that's the wrong way to initialize an app. easier to have a config local or even a global window.config unless you're initializing boot multiple times, but then i would window.boot = boot within the boot module itself.

i'm primarily against adding more options because that list is too long. anyone else wanna chime in?


Personally, I don't think auto require is a good idea. With the build file not contains auto require, I can build test pages for each of my components with the same files, it's not possible with auto require.


Can you elaborate?


I have a project works like a dashboard, it contains different type of charts like geomap linechart barchart datatable, they should looks concise, so I build all of them with different options on the same page to make the test easier(instead of configure them in the app, not easy as there could be some config limitation), the test page would like this:

    <title>widgets test</title>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
    <link rel="stylesheet" href="../build/build.css">
    <script src="../build/build.js"></script>

      var geomap = require('geomap');
      var linechart = require('linechart');
      var barchart = require('barchart');
      //build them all

If require('boot') is in build.js, I can't prevent the app from building.
The test pages could also make the learning of how each local component works very easy (since the API could be rapidly changing, I don't have too much comment with the API).


+1 for some way of turning auto require off


Auto-require is nice but I agree that it should be off by default. --auto-require seems more appropriate than --no-auto.


+1 for making this optional... on the fence about what the default should be - perhaps make the default the current behavior to avoid confusion.

@jonathanong, ok so it's another option, is that really an issue?


If you guys really want it, go head haha


--no-auto is not the most elegant but it does default component build's behavior as it currently is.
So for those of us whinging for this option LGTM!

@clintwood clintwood merged commit 76db52a into componentjs:master

1 check passed

Details continuous-integration/travis-ci The Travis CI build passed

I think this is a useful feature. For example, if you want to ship react components but also have a local "solo" development environment then off --no-auto is useful because ultimately you're going to bootstrap the solo component like this:

require('foo-component)({ ... })

I also don't understand the argument of being against many options in its own right. Many command line tools have many options, sub-commands and sub-command options that turn out to have a well defined interface and purpose. "Too many options" is not a constructive criticism.


Too many options is usually just a sign that a tool is doing too much and needs to be split, or isn't opinionated enough so it's not as useful. That's generally why component has it's CLI kept small, and plugins can extend it.


imo, too many options is a ridiculous problem. check the man page for ls(1) :p


@anthonyshort Agreed but I don't think that goes deep enough to be genuinely useful.

Clarification e.g.: component open isn't worth it, component build --no-auto is. I am stating the obvious, sorry, but the decision for these has nothing to do with counting the options list up to a subjective number. The aws(1) is complex, probably much more than is(1), but still simple, maybe simpler. That's because of properly applied design patterns. too many options in its own right isn't worth its weight as a design critique, that's all.


I agree though, --no-auto is useful :p

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Commits on Apr 19, 2014
  1. @kazupon

    Fix require automatically

    kazupon committed
This page is out of date. Refresh to see the latest.
Showing with 2 additions and 0 deletions.
  1. +2 −0  bin/component-build
2  bin/component-build
@@ -12,6 +12,7 @@ program
.option('-d, --dev', 'build development dependencies, use aliases, and use sourceURLs')
.option('-s, --standalone <name>', 'build a standalone, UMD-wrapped version of the component with the given global name')
.option('-R, --no-require', 'exclude require from build')
+ .option('-a, --no-auto', 'not require automatically')
.option('-p, --prefix <str>', 'prefix css asset urls with <str>', '')
.option('-b, --browsers <string>', 'browsers to support with autoprefixer')
.option('-c, --copy', 'copy files instead of linking')
@@ -98,6 +99,7 @@ var options = {
install: true,
verbose: true,
require: program.require,
+ autorequire:,
umd: program.standalone || program.umd || '',
prefix: program.prefix || '',
browsers: program.browsers || '',
Something went wrong with that request. Please try again.