Move makePathRelative from SDC to the FileSystem component

Blocker is in. Also moving to “file system” since that seems more appropriate.

Looking at core/modules/sdc from the latest 10.1.x branch and grep'ing for makePathRelative, I now find:

./src/ComponentPluginManager.php:        $altered_filename = $this->makePathRelativeToLibraryRoot($absolute_filename);
./src/ComponentPluginManager.php:      $altered_filename = $this->makePathRelativeToLibraryRoot($absolute_filename);
./src/ComponentPluginManager.php:      ? $this->makePathRelativeToLibraryRoot($absolute_path)
./src/ComponentPluginManager.php:  private function makePathRelativeToLibraryRoot(string $path): string {

Looking at the implementation:

  private function makePathRelativeToLibraryRoot(string $path): string {
    $library_provider_root = $this->moduleHandler
      ->getModule('sdc')
      ->getPath();
    $num_dots = count(
      array_filter(explode(DIRECTORY_SEPARATOR, $library_provider_root))
    );
    $dots = str_repeat('../', $num_dots);
    $path_from_root = str_starts_with($path, $this->appRoot)
      ? substr($path, strlen($this->appRoot) + 1)
      : $path;
    return $dots . $path_from_root;
  }

That seems kinda whacky and specific. 😉 Not sure we want to move this to the FileSystem component anywhere. 😅

@e0ipso: Can you re-confirm you think this is a good idea, and if so, update the summary to reflect the current state of the code and where you propose to move this private helper to?

Thanks!
-Derek

@dww thanks for catching this. Indeed, the code changed significantly after I created this follow up. Before it was more generic, and it might have made sense. However @alexpott pointed out we didn't need to make it generic since we already have Symfony's FileSystem::makePathRelative available. That's when we decided to make it specific.

Closing as won't fix.