ucdavis / sitefarm-distro-template

13 stars 9 forks source link

Support automatic library download via composer dependencies #15

Closed hawkeyetwolf closed 6 years ago

hawkeyetwolf commented 6 years ago

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:

  1. Create an issue/PR against the library's source repo to add a composer.json and then have the maintainers (or whoever owns the namespace) submit the project to packagist.
  2. Fork the library's repo into the components org that @robloch, I, and several others maintain. We will add the appropriate 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.
  3. Add a "repo" definition to this project's (the distro's) composer.json for each library. Note that the repo definition must go in the root composer.json, i.e., they won't be read from the profile's, unfortunately.

Let me know watcha think! Thanks.

mrkmiller commented 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"
    ]
  }
}
hawkeyetwolf commented 6 years ago

ack, so annoying when the package structure doesn't line up! (no, you're not missing anything). We could:

  1. Fork the bower repo and submit it to packagist directly, using the correct dir structure
  2. Submit issues to the bower repo or the ddotoh project to get things to align
  3. use a post-update (or post-install?) script to clean things up; this is probably the most sane route, methinks.
    "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?

mrkmiller commented 6 years ago

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.

hawkeyetwolf commented 6 years ago

Yeehaw! Sounds good, thanks @mrkmiller. FYI the script portion of the PR will need to go against the distro, 'cause scripts are "root only".