search

componentjs / component

frontend package manager and build tool for modular web applications
https://github.com/componentjs/guide
MIT License
4.55k stars 306 forks source link

Fix require automatically #554

Closed kazupon closed 10 years ago

vendethiel commented 10 years ago

The list keeps getting bigger :(

anthonyshort commented 10 years ago

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

jonathanong commented 10 years ago

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

@kazupon why would you use this?

anthonyshort commented 10 years ago

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: https://github.com/component/component/pull/554#issuecomment-40877571

kazupon commented 10 years ago

@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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

Can you elaborate?

chemzqm commented 10 years ago

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 commented 10 years ago

+1 for some way of turning auto require off

jb55 commented 10 years ago

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: https://github.com/component/component/pull/554#issuecomment-44648013

trevorgerhardt commented 10 years ago

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

clintwood commented 10 years ago

+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 commented 10 years ago

If you guys really want it, go head haha

clintwood commented 10 years ago

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

jasonkuhrt commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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

jasonkuhrt commented 10 years ago

@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 commented 10 years ago

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