generator-gadget
generator-gadget copied to clipboard
phase2
Add tota11y module as dev dependency for D8
In order to provide a good baseline for accessibility testing across all D8 projects, I would like to add the tota11y module as a dev dependency to the D8 composer.json template.
If this proposal is acceptable, I can create a PR, as I am already using this module on my current D8 project.
In general gadget avoids bundling direct application code beyond what's needed to select a distribution. This helps avoid responsibility on this project for the stability of resulting Drupal sites. As a Drupal module, maybe this should live in Octane or Lightning?
Gadget and grunt-drupal-tasks would absolutely be open to command-line testing tools that could be run by developers or CI processes.
I think this should be part of the D8 composer.json used in Generator. This is an accessibility testing tool in a similar vein to including Behat, PHPUnit, etc. Octane gets it's "require-dev" from our D8 template, so it can't just be added to Octane.
I can understand why we would be hesitant to add this for all Drupal 8 builds, though I do feel that accessibility testing should be a part of the baseline as much as possible.
I'm totally fine with adding it to Octane instead if that is the preferred approach. @mike-potter what is the blocker preventing Octane from having its own "require-dev" dependencies in a composer.json?
The "yo p2" generator for Octane takes the require-dev dependencies from the D8 template to ensure our environments for D8 and Octane are the same. That is why it needs to be added to the D8 template and not just Octane.
Well, we are already merging so we could merge with individual items preferring what's in gadget.
That said, testing tools do make a certain amount of sense. To reiterate my counters and expand in daylight:
- If we start adding modules, I think we need to work up to at least adding a Drupal build & installation test. I've been meaning to add another repo that represents the generated output of the latest master here, so maybe that's where such a test could be run.
- If we start adding modules, what's the criteria? Anything test related? Anything dev related? Should devel be added?
"yo p2" has no bearing on Octane right now, it's just gadget here that brokers it.
If merging dev dependencies between Octane and D8 gadget defaults is on the table, then I'd be favor of pursuing that approach and adding this module as an Octane dev dependency. That way, we can avoid opening up another issue of base D8 build stability. But Octane, as a distro that is supposed to represent best practices, seems like the natural place to add an accessibility testing tool and would fulfill the goal of providing an accessibility baseline.
@grayside We already include the drupal/coder module in require-dev. And I think "devel" should probably be included in require-dev also.
The criterion is whether or not we decide the "module" (library/whatever) is a "Best Practice Tool". We have a process for that (within Phase2 anyway). Others can propose additions via a Issue or PR like this one and we can discuss it. Otherwise, why do we have "behat" or "phpmd", etc. Those are not required to run Drupal (or even Drupal tests like phpunit is), so why do we have them? Because they represent our best practices.
Our accessibility team decided that Tota11y represents our best practice for accessibility testing tools, and we should respect their decision in their area of expertise.
This isn't an issue for Octane...this is an issue for Drupal projects in general. We want to ensure that all our Drupal-based projects (generated by yeoman) include our "best practice tools" for consistency. Octane is just our template for Lightning-based projects, and there could be other distributions in the future. This is a not distribution-specific issue. So I do not think doing a "merge" in Octane is the correct solution. It should be part of all our Drupal-based projects.
That's a fair point, though if coder is still a module, that's not why it's included, and it's not being placed with the modules. We use it as a definition of phpcs coding standards, for which it is loaded.
If this module is something Phase2 is saying all projects should use even if not built by P2, then let's proceed.
I feel I should note here that the only sense in which "Phase2" has spoken on the matter is that I feel strongly it should be used on all P2 projects, as does Catharine. As for all D8 projects, that's a bit more of a gray area, but I'd still be inclined to say yes. But I don't know if we want any sort of more official consensus before moving forward.
Does the module's ability to make sure it's in front of all developers & testers mean it has value to maintain here as opposed to asking teams to use https://chrome.google.com/webstore/detail/tota11y-plugin-from-khan/oedofneiplgibimfkccchnimiadcmhpe?hl=en?
Yes, I feel like a module that is included by default is more likely to encourage adoption than a recommendation to use a browser plugin. And agree with the point that it should be in front of all developers and testers by default. We're still leading a horse to water, but we're making the barrier to adoption that much lower.