taptapship / wiredep

Wire Bower dependencies to your source code.
MIT License
1.15k stars 142 forks source link

Breeze js and angular #167

Closed nojaf closed 9 years ago

nojaf commented 9 years ago

Hi,

I'm using the latest wiredep and I'm facing a small problem. I use breezejs and angular. The breeze main file must be loaded first, then angular and then some additional breeze-angular-wrapper files inside the breeze package but requiring angular. Is there any way I could setup this scenario?

f.ex

    <script src="../../bower_components/breeze-client/breeze.debug.js"></script>
    <script src="../../bower_components/angular/angular.js"></script>
    <script src="../../bower_components/breeze-client/build/adapters/breeze.bridge.angular.js"></script>
    <script src="../../bower_components/breeze-client/build/adapters/breeze.ajax.angular.js"></script>
dancancro commented 9 years ago

Hi @nojaf, any progress on this? I'm doing the same thing. I put the angular reference before the <!-- build:js> and the additional breeze references after the , but this seems like a hack. breeze.debug.js was injected by wiredep.

I'm puzzled why there isn't more than "Wire dependencies to your source code" or from grunt-wiredep "takes a look at all of the components you have, then determines the best order to inject your scripts in to your HTML file" to explain how wiredep chooses and orders the things it injects. I came across wiredep by using generator-angular-fullstack. It's not very clear to me what's going on.

nojaf commented 9 years ago

No progress on my end, I'm doing a similar hack.

stephenplusplus commented 9 years ago

wiredep injects references based on how the components you use list their dependencies in their bower.json files.

Can you list the Bower dependencies you're using with a link to their bower.json as well as the expected and actual results you expect from wiredep?

dancancro commented 9 years ago

Ideally, I'd like a short story explaining step by step what happens when the wiredep task runs. I've tried to piece it together. This is how I understand it so far.

1) Read the .bower.json files in the directories under bower_components/, I think.
2) Look at the "dependencies" section to determine dependencies. After reading all the .bower.json files, determine the order to inject things so that required things precede dependent things. 3) For each one that meets some condition try to insert a <script> tag into the target file (e.g. index.html) 4) If the script is already there, even if it is commented out, don't do the injection 5) If something happens then don't inject it and output " was not injected in your file. Please go take a look at ___ then manually include it in your file". Continue with the process. 6) If some condition then display "Warning: Cannot read property 'main' of undefined Use --force to continue." Terminate the process. Don't say which dependency had the problem.

and so on.

Here is a plnkr of my project files. Everything works but some things had to be hard coded into index.html that I think should be automatically injected.

I don't understand how wiredep chooses which javascript files to inject scripts for. My bower_components directory has 636 javascript files and wiredep is injecting scripts into index.html for only 31 of them. Does it look at my application code to see what's needed?

stephenplusplus commented 9 years ago

It uses your bower json to know what dependencies your project has. It then goes to each of those dependencies bower jsons to see what their dependencies are (for sorting) and main file is (to know what to inject). If the path we're about to inject is found in the file we're about to change, it is skipped. This behavior is going to be removed for the next release.

Closing as this issue seems like an matter of components not listing bower.json properties properly. Wiredep can only work at 100% when the components used play by bower's rules.

dancancro commented 9 years ago

There probably isn't a bug here, but it would be nice if some documentation were added. What I wrote is just my guess at what's going on and it's incomplete.

For example, I have "flot": "~0.8.3" in my bower.json file. "flot" is a bower package containing 19 javascript files and the following .bower.json:

{
  "name": "Flot",
  "version": "0.8.3",
  "main": "jquery.flot.js",
  "dependencies": {
    "jquery": ">= 1.2.6"
  },
  "homepage": "https://github.com/flot/flot",
  "_release": "0.8.3",
  "_resolution": {
    "type": "version",
    "tag": "v0.8.3",
    "commit": "453b017cc5acfd75e252b93e8635f57f4196d45d"
  },
  "_source": "git://github.com/flot/flot.git",
  "_target": "~0.8.3",
  "_originalSource": "flot"
}

The only javascript file from this package that I want injected is jquery.flot.time.js, but wiredep isn't injecting it. I don't know why it's not doing this or why/how it would choose the one I want among the 19. I can't tell whether a bower rule is being broken and I don't know what I need to do to fix it.

Likewise, "angular-bootstrap": "~0.12.0" is in my bower.json file. This package contains 4 javascript files. wiredep is correctly injecting ui-bootstrap-tpls.js and not ui-bootstrap.js. I don't know why.

bootstrap.file-input.js is another one that's not being injected. At least with this one wiredep is alerting me that it knows I want to inject it but for some reason it can't and I should do so manually. I can do it manually, but I don't understand why it knows I want it.

It all seems very mysterious and I think a little documentation would clear the whole thing up.

stephenplusplus commented 9 years ago

More documentation is a great idea. I added a couple sections to the readme, I hope this helps: https://github.com/taptapship/wiredep#how-it-works

In the case of Flot, when they say "main": "jquery.flot.js", they're telling Bower, "this is the file that represents this package". The tooling ecosystem (where wiredep lives), then comprehends this agreement and uses that file as the file to inject.

The tooling system can make guesses, but it's not a reliable system. As an example of a "safe guess", wiredep will guess that a file named "jquery.js" in the root directory of a package called "jquery" is the main file, but only as a last attempt after first looking to see if the package defined a main file already.

As explained in the readme, you can use "overrides" when you know better than the package. That sounds like the case with Flot, because you're not interested in what they say is the main file.

With angular-bootstrap, take a look at their bower.json - the main file is the file that wiredep injects. As far as a tool can know, it did its job. It found the file and injected it.

bootstrap-file-input is different. It's a package that doesn't have a bower.json. You get the warning because wiredep couldn't do any magic for you, so it lets you know you'll need to intervene.

Hope this helps!