Explore the posibility of a different setup for the project, composer expansion and symlinking process

Core systems, for example LibraryDiscoveryParser, require libraries to be placed in the Drupal root or module-relative.

I have a project → which dynamically determines the location of library files, for this example it is a test module in a subdirectory of the project.

The gitlab templates as they are right now keep the module files outside the Drupal install. Then symlink the module files to a typical location inside modules/custom via symlink_project

When PHP attempts to gets the location of the file, via reflection, it is outputting the true location of the file. That is, outside of the Drupal installation.

When I try to use code in CI, it will not work since the files lie outside of the Drupal install.

My guess is that there could be other Drupal projects failing, however unless assertions are very thorough, they won't notice assets are not loading.

--

My only suggestion at this time, is to actually copy, not symlink, files to the appropriate directory.

This could be done by further modifications to the project composer.json file, by adding a path repository, and modifying symlink_project.php to instead copy files.

Or we could just set up CI so it checks out the module code where it belongs in the first place, and build a running Drupal project around it (a few directories above). Im sure there are more ways to do this...

The code I used to workaround the problem can be found at https://git.drupalcode.org/project/pinto/-/commit/ac26e665ce5f703faffbda.... Note the changes to `.gitlab-ci.yml` and a creation of a modified symlink_project, at `.gitlab/custom_symlink_project.php` (which actually copies, not symlinks)

Thanks for the links and examples, they do help a lot.

My thinking about the project set up is similar. GitLab CI puts the project in /builds/project/THE-MODULE/ and then we build everything on that folder.

We could explore building the project in /builds/project/full_project and then copy (not symlink) the module code. If using the above folder is not an option (haven't tried yet), we can still have a full_project folder in a location that we're allowed and build everything there. Then for module related jobs, we use the original pristine module folder (ie: linting jobs), and for the project related jobs (ie: running testing) we use the projects folder.

So I fully agree with you on this one.

Just hit on this again in another project 🤦

https://git.drupalcode.org/project/role_enum/-/merge_requests/2/pipelines

Lucky I had a bunch of code in .gitlab-ci.yml / .gitlab/custom_symlink_project.php I could copy 😇

Given that the differences in the script you use are so small

    $source = sprintf('%s/%s', $projectRoot, $item);
    $target = sprintf('%s/%s', $moduleRoot, $item);
    \is_file($source)
      ? $fs->copy($source, $target)
      : $fs->mirror($source, $target);

vs

$fs->symlink($rel . $item, $moduleRoot . "/$item");

we could definitely implement a variable to switch between symlink and copy. That could go in the current templates, without needing a big refactoring as it would also need to be selected.

It could be something like this (untested):

// In the hidden-variables.yml file
_COPY_STRATEGY: "symlink"

// In the symlink_project.php script (which could be renamed or just leave as is)
$copy_strategy = isset($argv[3]) ? $argv[3] : getenv('_COPY_STRATEGY');
$source = sprintf('%s/%s', $projectRoot, $item);
$target = sprintf('%s/%s', $moduleRoot, $item);
if ($copy_strategy === 'symlink') {
   $fs->symlink($source, $target);
}
elseif ($copy_strategy === 'copy') {
    \is_file($source)
      ? $fs->copy($source, $target)
      : $fs->mirror($source, $target);
}
else {
  // Fail or do the "symlink" as fallback I guess.
}

Feel free to create a different issue for this part if that's something worth exploring.