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

Support automatic library download via composer dependencies #15

Closed
hawkeyetwolf opened this issue Nov 18, 2017 · 4 comments
Closed

Support automatic library download via composer dependencies #15

hawkeyetwolf opened this issue Nov 18, 2017 · 4 comments

Comments

@hawkeyetwolf
Copy link
Contributor

hawkeyetwolf commented Nov 18, 2017

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
Copy link
Contributor

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
Copy link
Contributor Author

hawkeyetwolf commented Nov 21, 2017

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
Copy link
Contributor

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
Copy link
Contributor Author

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

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

No branches or pull requests

2 participants