Consider making `content` the config root

[fklein-lu]

The setup of HM Base currently considers the root directory as the custom code root directory. As a consequence, PHPCS, PHP unit tests, the Composer file etc. are place inside of the root directory.

I do think however the it would be best the place most if not all of these things inside of content.

Because once you add NPM on top, you end up in weird scenarios where you sniff and lint from content, but run the PHP unit tests from a config file in root. If you have custom unit testing code, it's probably in content, and it all is rather confusing.

[mikeselander]

I would support this move. Condensing the root of config files closer to the code it's checking makes sense and this also moves our configuration for VIP and platform projects closer in organization. We wouldn't be able to move .gitmodules, but everything else would be fine.

[mattheu]

I don't really see the need for this change.

• Our HM projects just are different from VIP projects with a different structure. Other than a very small amount of effort to configure things differently, I'm not sure I understand the benefit here.
• Having content at the top level is clearer. When I open the whole project in my editor, it will pick up config for PHPCS and eslint automatically.
• I have always run sniffers/linters from the project root directory in the past without problem. Yes, you have to configure which directories to include, but you still have to do this if config lives in content so I see no advantage to moving this to content.
• I have also always run npm at root level too, and again I see no difference moving this to content.

Now - On a recent project composer, it was configured to move the vendor directory into the content directory. This caused problems with Human Made Coding Standards which cannot then handle this if it is then run from root (paths are messed up, it assumes it is installed in /vendor). The only solution I can see is to move PHPCS configs to the content directory.

BUT I don't really see why you need to move vendor into the content directory in the first place - just install composer dependencies in /vendor as per composer default. You can still specify that Plugins/MU Plugins are installed elsewhere by composer if required.

[fklein-lu]

[...] you still have to do this if config lives in content so I see no advantage to moving this to content.

There is definitely an advantage in so far as there's less to exclude in content. Good maintenance of the basic sniffing and linting configs offsets this advantage though.

This caused problems with Human Made Coding Standards which cannot then handle this if it is then run from root (paths are messed up, it assumes it is installed in /vendor).

You can use --standard=<path> with WPCS, and it's pretty flexible on where the configuration file lives, and where the standards live.

BUT I don't really see why you need to move vendor into the content directory in the first place [...]

Having vendor at the root is fine, as long as it is only used for development dependencies, as I consider that all code that runs on a production site should be in content.