Closed rayrigam closed 11 years ago
@rayrigam, thanks for an active contribution. I found at least one issue with paths that are actually URLs, not files in the local filesystem. The logic with checking each path as a file in the local filesystem was added with shim support, so I need some time in order to fix it. I also want to make some code refactoring for the namespace mapping. You should use the older version of the bundle, while I'll fix this issue.
@IgorTimoshenko thanks for looking into this! I'll keep using the older version for now as you suggested. Best!
@rayrigam, check your application please. I made the appropriate changes for the 1.0.x
branch (the new one tag is currently not available until I'll be sure that all works ok) and for the 2.0.x
branch with some refactorings. Thanks!
@IgorTimoshenko thanks! I checked the new version and it works. It now takes the external URLs defined in the config paths and if it cannot find the asset at the first URL defined in the array, it uses the fallback. One thing to mention though is that for internal fallbacks to work, one needs to define the entire internal path (it does not use the base_directory defined in the config.yml file) as follows:
hearsay_require_js:
base_directory: %kernel.root_dir%/../src/MyVendor/MyBundle/Resources/public/js
paths:
jquery:
location: [//ajax.googleapis.com/ajax/libs/jquery/2.0.0/jquery.min, %kernel.root_dir%/../src/MyVendor/MyBundle/Resources/public/js/libs/jquery/2.0.0/jquery.min]
external: true
@rayrigam, yes, you're right but it's another issue that is related to the getRealPath
method, so I close the current issue. Anyway, I know about it and I'll fix it in the nearest future.
thanks!
With the latest 1.0.5 and 2.0.x-dev versions of this bundle, defining external locations in the Paths are not working. If I use either:
Or:
I get the following error while loading the page in the browser:
However, if I use an internal location like the following, I get no script errors, and everything loads fine:
It is to notice that the issue was introduced with a recent commit. Up until commit #45c852aeb444aedf8211838c3512acbb146b4d72, there was no problem with this.