Fail gracefully when $this->appDir./sites not found

[JParkinson1991]

During installation of this package, during early site builds where the 'sites' directory does not exist under $this->appDir/sites an InvalidArgumentException or a DirectoryNotFoundException will be thrown by the Symfony Finder package.

This can cause failed installations and also causes the drupal:paranoia command to fail.

These exceptions should be caught by the Installer and handled gracefully.

It is safe to assumes public files directories do not exist under $this->appDir if the sites directory is not found.

Expected behavior

Failing gracefully without attempting to link the non existent directories.

Actual behavior

Uncaught exception breaking package installation, plugin events and the provided commands.

Steps to reproduce

During install

1. Create a project without a 'sites' directory inside the configured app-dir
2. Require drupal-composer/drupal-paranoia
3. See the uncaught exception in console output

When running as a command

1. Create a project without a 'sites' directory inside the configured app-dir
2. Require drupal-composer/drupal-paranoia
3. Run composer drupal:paranoia
4. See the uncaught exception in console output

Possible solution

#20

[JParkinson1991]

Pull request created #20

Catches core Exception due to different exceptions that can be thrown by the Symfony Finder component.

[jkribeiro]

@JParkinson1991 Do you have a case where the folder $this->appDir/sites would not exist when running the command or composer install/update?

Just asking because I never saw this case.

[JParkinson1991]

@jkribeiro I tend to usually framework my Drupal stacks manually, so i dont use the drupal-project template.

When im building my project i like to test that all scaffolding and paranoia etc is working before i start adding in sites, so in early stages of project builds i dont have a sites folder whilst im testing this plugin along with the drupal/core-composer-scaffold plugin.

Running this plugin without a sites directory is an edge case that probably wont affect many users for sure. But i do think it should be handled and not cause this plugin to break.