Description
Description
I was upgrading my application to use asset-mapper
(coming from webpack-encore
) and inspired by the very useful AssetMapper Livestream of Ryan, thanks for that!
I came across the following; since my application is sort of multi-application as it consists of a website, dashboard, (easy-)admin etc etc. I have the following assets
structure in my project.
assets/
admin/
dashboard
website/
...
In 6.3
the AssetMapper
relied on the url
of the package (within importmap.php
) and that way loaded the packages externally. That all worked, but again inspired by the livestream to get all the new features, I upgraded to 6.4
and the way packages are loaded externally (by default) changed to loading the packages locally (in assets/vendor
by default).
I updated my importmap.php
to drop the url
usage (since it's been made deprecated directly in 6.4
) and switched to the version
keys. And ran the new importmap:install
command, which downloads the packages locally, cool!
I then encountered the following error:
Since the packages were already installed (locally, in assets/vendor
like it supposed to) I was pulling my hairs out for some time to find out what I did wrong... 😫
It finally came to mind that AssetMapper
couldn't find the assets/vendor
directory, and thus the packages, because of my config, not having the whole assets
root:
framework:
asset_mapper:
paths:
assets/dashboard: 'dashboard'
assets/easy_admin: 'easy_admin'
assets/website: 'website'
As I didn't want to make my whole assets
directory being available publicly, the application didn't automatically load the assets/vendor
directory. Adding assets/vendor: 'vendor'
to the paths solved my problem 😅
framework:
asset_mapper:
paths:
assets/dashboard: 'dashboard'
assets/easy_admin: 'easy_admin'
assets/vendor: 'vendor' # <===
assets/website: 'website'
So my suggestion would be to:
- Add the
assets/vendor
(or more precisely theframework.asset_mapper.vendor_dir
config) directory to theframework.asset_mapper.paths
array by default. Which seems logical as it would always need to be publicly available. - Have a better exception message for this specific case, which would ease solving the issue.
Example
No response