Paths dependent on install (Drupal vs standalone)

[evanmwillhite]

If you're running Pattern Lab inside of Drupal (e.g., DRUPAL/themes/contrib/emulsify/pattern-lab/public/), the paths determined by this extension are different. This tries to fix the broken ones in Drupal while keeping it working in standalone Emulsify installations

[waako]

This does make paths work if accessing pattern-lab through:
site-name/themes/contrib/emulsify/pattern-lab/public
but then broken for localhost:3000/pattern-lab/public/

In the case of emulsify (or theme based on emulsify) I've found this relative path seems to work everywhere: ../../../../ regardless of the component depth it's attached to.

[hawkeyetwolf]

This PR is a really clever and important fix! Is there a way to avoid hard-coding the components directory name? E.g., by searching for a file we can absolutely guarantee is present with all PatternLab installations, like the config.yml or PatternLab console CLI, then deducing the correct path from there?

In case it's helpful, we can determine the theme name from the string passed to attach_library() ('theme_name/library_name'). The most reliable way to then determine the theme directory would be via globbing for theme_name.libraries.yml and calling dirname() on the result.

The bigger issue I see is the assumption that the "themes" directory lives in the webroot. This will work for most Drupal 8 sites, except those who put their theme in a sites sub-directory. And almost all Drupal 7 sites would have their theme either in /sites/all or another sites sub-directory.

I'm not sure there's a good way to get around this issue. Relative paths assume a certain structure to the patterns directory. And I don't see a way to reliably build absolute paths given the "themes" directory structure variation I noted above. The only "bullet-proof" option I see is a "themePath" configuration setting, as proposed in #11.