[emulsify-ds/compound/issues/57] Dependency Improvements & Refactoring & Renaming

[emircanerkul]

Dependency Improvements & Refactoring & Renaming

With this PR, All components work as individuals. To accomplish that some hooks are written and webpack configs have been changed. Drupal automatically explores all sub-libraries.

Libraries in the global file are moved to their own files.

Dist folder output: All files are individually exported

┆Issue is synchronized with this Clickup by Unito

[ModulesUnraveled]

This might make more sense to go in the Emulsify Twig module rather than in each theme. If it's going to be the recommended way to write libraries, I'd hate for someone to not know what this is, and delete it from their theme, and then ask us why their libraries don't work... If it's in the module (which is a Drupal dependency) they can't delete it, and keeps "required" code out of their custom codebase.

[emircanerkul]

To do that, we also need to change the code a little bit. (Need to get the active theme and dir)

emulsify-drupal/emulsify.theme

Line 14 in 79f34c5

$theme_name = basename(__FILE__, '.theme'); // compony

Or we can just wait for this feature to become included in the core https://www.drupal.org/project/drupal/issues/3092496

We can propagate the idea of If you don't know and if all works good, DON'T touch anything! 😄

[callinmullaney]

@emircanerkul Thank you for submitting this work. I did a light functional test on this and the functionality you are adding is great! I think this is likely the direction we would like to take emulsify as it allows components to work a bit more independently and removes a manual step we all need to do with Drupal. Creating a drupal library to attach somewhere.
I'm in somewhat of an agreement with ModulesUnraveled assessment that this code would be better managed from a module or maybe even a base theme. Because Emulsify is a starterkit for custom theme's this means this large php function would need to carry over. Also, we would need to add some extra tooling to the emulsify to check php formatting and Drupal deprecation's if we wanted to support this code long-term.
The issue you linked has a related issue that takes a different approach and is seeing a bit more traction. I'm keeping an eye on this one as I would definitely like to see this functionality implemented somewhere on this project: https://www.drupal.org/project/drupal/issues/3075427
That being said, this feature as well as several common preprocessing functions have made the rounds in our internal discussions. Their might be an opportunity here to introduce a base theme where we could contain this functionality in a more isolated space but still see it's benefits. I'm going to place this PR on hold for now and update it with a path forward if the linked issue above is merged or a base theme is being developed.
Thanks again for all your efforts!

[emircanerkul]

@callinmullaney thanks to you too.

[sync-by-unito]

➤ Callin Mullaney commented:

This ticket/issue is no longer relevant. Emulsify Core 2.x compiles component JS/CSS into their own files, is node v20 compliant, and supports SDC in drupal environments. This negates the need for the auto-attach library function request. Closing.