Bower install javascript lib but not include in config.js

Norbert Hartl wrote:
> Well, the javascript files are in the same repository as the amber project. So it isn't that easy to check them out. And those are not modules more kind of a configuration for angular/ionic. Basically I want to use amber for ionic (mostly angular) wiring. I need to load ionic/angular base first, the n amber and finally a few javascript files

Why not in parallel? Amber does not start anything anyway until you call amber.initialize yourself. So just put all app-level dependencies in deploy.js, along with amber/deploy itself.

> making the wires between angular and amber.

Those you can load in the callback itself, by issuing the nested require call, like `require(["glue_module_1", "glue_module2"], function (glue1, glue2) { glue1.doSomething(); glue2.doSomething(); amber.initialize(...`


--
You received this message because you are subscribed to the Google Groups "amber-lang" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

On 4/13/15, Norbert Hartl <[hidden email]> wrote:
> I do not want to hijack this thread but I have a similar question right
> now.

Thats OK. This is a topic people on this list have been struggling
with the last 18 months ...


> What would be the best way to integrate javascript files into the require.js
> process that are no bower components?

May I ask you to do an attempt at answering this yourself in the
upcoming days here.

https://github.com/amber-smalltalk/amber/wiki/FAQ

You may just put the question there and a few keywords for the answer
as a start.


--
You received this message because you are subscribed to the Google Groups "amber-lang" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "amber-lang" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

Of course you must have directory foo if you have foo.amd.json. That what it's about. Read herby/amd-config-builder README.

But no one ever said it must in bower_components. It's recommended to bring external dependencies via bower, though.

--
You received this message because you are subscribed to the Google Groups "amber-lang" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

Dňa 13. apríla 2015 17:17:57 CEST používateľ Norbert Hartl <[hidden email]> napísal:
You don't get what foo.amd.json is about. It's not about consumer-of-dependencies foo, it's about provider-of-dependency foo. In no case you should use .. in paths mapping, it means you do something wrong.

--
You received this message because you are subscribed to the Google Groups "amber-lang" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "amber-lang" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "amber-lang" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

Dňa 13. apríla 2015 20:33:42 CEST používateľ Norbert Hartl <[hidden email]> napísal:
No. Look the README mentioned below. The symbol it defines xan be any. Look in helios, for example. There is lots of .amd.json files there.

> associate it with an location = base path of the resource where
> relative resources are looked up.
> I try to build an ionic app with amber inside. So my directory layout
> is
>
> project root/
>     amber/
>         io-local.amd.json

Why are you creating file named io-local.amd.json at all if you don't have ditectoru io-local in project? As I said, read the README in github repo herby/amd-config-builder and understand the purpose of .amd.json files.

Json? It is just data. It does nothing.

> js files. But there seems to be no way (that I see) to load it that
> way and treat as dependency target.

Everything can be loaded, it just must have a mapping and if it is legacy, not amd module, it must list of dependencies and global that is exported shimmed.

>
> So what I'm doing wrong?

Probably lots of details. You must endure the pain for a while umtil it all clicks, I presume.

>
> Norbert

--
You received this message because you are subscribed to the Google Groups "amber-lang" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

Herby,

thanks for your info. If my previous mails sounded a bit harsh I like to apologize. But after a few hours getting more and more confused I was (let's say) slightly frustrated.
That was a typo. I meant deps.js

>> js files. But there seems to be no way (that I see) to load it that
>> way and treat as dependency target.
>
> Everything can be loaded, it just must have a mapping and if it is legacy, not amd module, it must list of dependencies and global that is exported shimmed.
>
>>
>> So what I'm doing wrong?
>
> Probably lots of details. You must endure the pain for a while umtil it all clicks, I presume.

I had module definitions that had at the same time directories with the same name in bower_components. Whatever I did it tried loading it from bower_components making me think it was always looking for names of an amd.json file. To me the directory scanning is completely counter intuitive and while being useful has all sorts of gotchas.
Now I defined most single sources just in local.amd.json and added shim depends for them. That worked out well so I could even remove the nested require statements in the index.html.
Taking my filesystem into account using ".." looks indeed feasible because of my special case. I changed that to look being part of the project but those are just symlinks pointing to a ../../… resource directory. I can't see a better way doing it.

One of the gotchas of the directory scanning turned out to be a bug. You can check that by installing the bower component googlemaps-amd. They have a directory named hasOwnProperty under a test hierarchie. The semantics of remembering directory names does not work if the property is already present. For that it would be needed to exclude the properties of Object when building the map. I can provide a fix for it and I hope I find some time this week.

Norbert

--
You received this message because you are subscribed to the Google Groups "amber-lang" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

Norbert Hartl wrote:
> Herby,
>
> thanks for your info. If my previous mails sounded a bit harsh I like
> to apologize. But after a few hours getting more and more confused I
> was (let's say) slightly frustrated.

No need to apologize, my communication is also not salonfahig. ;-)

>
> I had module definitions that had at the same time directories with
the same name in bower_components. Whatever I did it tried loading it
from bower_components making me think it was always looking for names of
an amd.json file. To me the directory scanning is completely counter
intuitive and while being useful has all sorts of gotchas.

Sure, but it was the simplest at the time that is not hardcoded to any
"place to search" like bower_components, which was the primary goal from
the beginning (that's why I get angry when people tell it is bound to
that dir). I did not thought of use case where same directories are
there at the same level of deepness often. When they happen, bad luck,
but simple things are simple are hard things are hard. If you must have
same directories try to make it so that the ones that are needed to be
found are less deep than those others instances of them.

> Now I defined most single sources just in local.amd.json and added
shim depends for them. That worked out well so I could even remove the
nested require statements in the index.html.

Sure, that's what I wanted to suggest, as well - once you have
dependencies set up, you can just require(["app"], ...) and just have
all needed things listed in deploy.js (later you can even take it away
from there and put it locally where they belong using packages'
`imports:` if they are needed specifically by a few Amber packages (if
they are needed by app as a whole, deploy.js is a good place)).

> Taking my filesystem into account using ".." looks indeed feasible
because of my special case. I changed that to look being part of the
project but those are just symlinks pointing to a ../../… resource
directory. I can't see a better way doing it.

All amd.json files specify what is _inside_ a module filetree, not
outside of it. Since the search goes over the whole project tree, you
can have those modules in different places all over the tree, but
amd-config-builder which is used in grunt devel and grunt deploy finds
them and generates proper config.js for you.

../ is tight coupling of separate pieces. Not the right thing to do.

If it is all local to your project, you can put it in local.amd.json;
but if you treat any part of it external, even just a bit (like, it is
taken from different source, may be updated, maybe moved to other
location etc.; IOW it is external even if installed by hand), that's
what libdir.amd.json files are there for, as you probably understood
from the README.

IOW, it is all about keeping mapping local to the resource it maps, so
the pieces are loosely coupled. You can also get a big picture by
reading "Lego pieces metaphor" page from the amber wiki.

> One of the gotchas of the directory scanning turned out to be a bug.
> You can check that by installing the bower component googlemaps-amd.
> They have a directory named hasOwnProperty under a test hierarchie.
> The semantics of remembering directory names does not work if the
> property is already present. For that it would be needed to exclude
> the properties of Object when building the map. I can provide a fix
> for it and I hope I find some time this week.

Oh. Sure, I just use plain object-as-a-map. It must blow if a dir is
named like an existing property (which idiot would name a directory
hasOwnProperty, including the spelling?!)

> Norbert

Herby

--
You received this message because you are subscribed to the Google Groups "amber-lang" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.