Closed hawkeyetwolf closed 6 years ago
Big fan of the idea. We have an existing issue ucdavis/sitefarm_seed#170 to do just that. However, I've hit a speed bump with the package naming that happens when pulling the package. For example, the Wordcount plugin for CkEditor gets pulled in with a wrapping directory /libraries/word-count-ckeditor/wordcount
so that the module trying to use the library can't find the js files since it is looking to libraries/wordcount
. Perhaps I just missed something simple in my setup? Any ideas?
I'm using oomphinc/composer-installers-extender
"extra": {
"installer-types": [
"bower-asset",
"npm-asset"
],
"installer-paths": {
"docroot/libraries/{$name}": [
"type:bower-asset",
"type:npm-asset"
]
}
}
ack, so annoying when the package structure doesn't line up! (no, you're not missing anything). We could:
"scripts": {
"post-update-cmd": [
"[ -d web/libraries/word-count-ckeditor ] && mv web/libraries/word-count-ckeditor/wordcount web/libraries && rm -rf web/libraries/word-count-ckeditor"
]
}
What say you?
I was hoping to avoid needing scripts, but I think number 3 is probably our best bet. I'd prefer not to fork repos if we can help it, and I'm not sure how feasible/timely number 2 would be. I'm gonna work on an implementation with the script solution in 3. At the very least it would work as a simple stop-gap so that we can at least move this forward.
I'm gonna close this issue as a duplicate of ucdavis/sitefarm_seed#170 since we've been trying to keep all issues over in the main profile repo.
Yeehaw! Sounds good, thanks @mrkmiller. FYI the script portion of the PR will need to go against the distro, 'cause scripts are "root only".
The SiteFarm profile includes the complete code of seven libraries. Let's figure a way around that. If any of them are available on npm or bower, use asset-packagist to require them. Otherwise, we have a few options. In descending order of preference:
composer.json
and then have the maintainers (or whoever owns the namespace) submit the project to packagist.composer.json
and then submit it to packagist. If you'd like to go this route for any of the libraries, just let me know which ones and I'll take care of it.composer.json
for each library. Note that the repo definition must go in the rootcomposer.json
, i.e., they won't be read from the profile's, unfortunately.Let me know watcha think! Thanks.