Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Install assets to vendor directory instead of to public directory #525

Open
jontjs opened this issue Jan 3, 2024 · 2 comments
Open

Install assets to vendor directory instead of to public directory #525

jontjs opened this issue Jan 3, 2024 · 2 comments

Comments

@jontjs
Copy link
Contributor

jontjs commented Jan 3, 2024

Describe the bug
Any time you run Symfony's assets:install command, the public/bundles/fmelfinder directory is removed, so you then have to run elfinder:install to (re)install the assets. One workaround is to add elfinder:install to composer.json's auto-scripts section but it has to be AFTER assets:install.

This differs from (for example) friendsofsymfony/ckeditor-bundle which needs to have its ckeditor:install command run BEFORE assets:install. This is because its command puts the assets into vendor/friendsofsymfony/ckeditor-bundle/src/Resources/public, and assets:install then copies them to public/bundles/fosckeditor.

To Reproduce
Install this bundle, following all its instructions. Then at a later date run composer install. The public assets will no longer be present, so the finder fails with a javascript error Script error for "elfinder".

Additional context
I think the "Symfony standard" way for bundles to handle assets is the way friendsofsymfony/ckeditor-bundle does it, i.e. download the assets into vendor/ so that assets:install will copy (or symlink, according to the user's preference) them into public/bundles/. I've not managed to find any official guidance on this, but it is what Symfony's command does.

Note that changing this would, to my mind, constitute a breaking change because any workarounds people have made for the current behaviour may no longer work as expected.

@helios-ag
Copy link
Owner

helios-ag commented Jan 4, 2024

actually good point @jontjs, probably worth to change behavior, and mark next version as major, with such changes

@jontjs
Copy link
Contributor Author

jontjs commented Jan 4, 2024

I'll try to get a PR ready for it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants