Fix require automatically #554

Merged
merged 1 commit into from Jun 23, 2014

Projects

None yet

10 participants

@kazupon
Contributor
kazupon commented Apr 19, 2014

No description provided.

@vendethiel

The list keeps getting bigger :(

@anthonyshort
Contributor

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

@jonathanong
Contributor

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

@kazupon why would you use this?

@anthonyshort
Contributor

Yeah good point—
Sent from Mailbox for iPhone

On Sat, Apr 19, 2014 at 11:53 AM, Jonathan Ong notifications@github.com
wrote:

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

@kazupon why would you use this?

Reply to this email directly or view it on GitHub:
#554 (comment)

@kazupon
Contributor
kazupon commented Apr 20, 2014

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

require('boot')({ foo: 'bar'});
@jonathanong
Contributor

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?

@chemzqm
Contributor
chemzqm commented Apr 21, 2014

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.

@jonathanong
Contributor

Can you elaborate?

@chemzqm
Contributor
chemzqm commented Apr 21, 2014

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:

  <head>
    <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>

  </head>
  <body>
    <script>
      var geomap = require('geomap');
      var linechart = require('linechart');
      var barchart = require('barchart');
      //build them all
    </script>
  </body>

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).

@stephenmathieson
Contributor

+1 for some way of turning auto require off

@jb55
jb55 commented May 30, 2014

We almost always pass data into our app constructor in all of our app components. Relying on a global variable for configuration seems pretty strange.

On Fri, May 30, 2014 at 6:04 AM, Stephen Mathieson
notifications@github.com wrote:

+1 for some way of turning auto require off

Reply to this email directly or view it on GitHub:
#554 (comment)

@trevorgerhardt
Member

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

@clintwood
Contributor

+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?

@jonathanong
Contributor

If you guys really want it, go head haha

@clintwood
Contributor

--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 Jun 23, 2014

1 check passed

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

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)({ ... })
@jasonkuhrt
Member

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.

@anthonyshort
Contributor

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.

@stephenmathieson
Contributor

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

@jasonkuhrt
Member

@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.

@anthonyshort
Contributor

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