Toolkit v5.0.0 Proposed Changes

[emilyrohrbough]

Proposed Changes

Wdio

• Fix Huge viewport inconsistencies: Inconsistent Screenshot Widths when using FormFactor: 'huge' #137
  • IN REVIEW: [v5] Fix Form Factor Size and Naming Issues #279
• Update Selenium Grid Version to 3.14.0-helium Update Selenium Grid Version to 3.14.0-helium #190
  • IN REVIEW: [V5] use selenium pie #286
• Fix form-factor screenshot naming: Incorrect Screenshot Naming When Form Factor Testing #248
  • IN REVIEW: [v5] Fix Form Factor Size and Naming Issues #279

Webpack

• Re-enable Minimized css-loader Re-enable Minimize via css-loader #122
  • IN REVIEW: [V5] MVB Dependencies & Dev Dependencies #282
• Accepts or search for project defined Autoprefixer config: Webpack shareable config is not generating -webkit-flex styles #110
  • IN REVIEW: [V5] MVB Dependencies & Dev Dependencies #282

Axe

• Install Minimized Version of axe-core: Install the Minimized Version of Axe-Core on Dom #178
  • IN REVIEW: [V5] Remove Axe Service #285
• Review and fix axe-service default configuration to align with our standards: Review "Document contain at most one banner landmark" axe rule #243 (comment)
  • IN REVIEW: [V5] Remove Axe Service #285
• [] Unpin Axe-core dependency: Update to latest version of axe-core #259
  • IN REVIEW: [V5] Remove Axe Service #285

Scripts

- [ ] remove Arabic translation from supported locales: #229

• Remove aggregate-translations scripts references in favor of using to https://github.com/cerner/terra-aggregate-translations and update toolkit to pull in the released module as peer. Use terra-aggregrate-translations module #273
  • IN REVIEW: [V5] Remove Aggregate Translations Script & Locale Config #283

Dependencies

• Remove nightwatch: Warning about requiring a peer of nightwatch despite terra-toolkit warning against using nightwatch #165 & Remove nightwatch dependency #172
  • IN REVIEW: [v5] Remove nightwatch! #272
• Update Dependencies to Latest Versions: Update dependencies to latest stable release #161
  • IN REVIEW: [V5] MVB Dependencies & Dev Dependencies #282
• Update Dev Dependencies to Latest Versions: Update dev dependencies to latest stable release #160
  • IN REVIEW: [V5] MVB Dependencies & Dev Dependencies #282
• Make webpack dependencies - peer dependencies
  • IN REVIEW: [V5] MVB Dependencies & Dev Dependencies #282

Issues to Consider Won't Fix in v5

• Injecting theme code in code split bundles Code splitting bundle segregation for theming #200
• Optimizing moment JS locale data https://github.com/cerner/terra-toolkit/issues/193

[emilyrohrbough]

This bug was logged: #257. It discusses default configuration issues and makes me wonder if how we should handle this. We could:

• close as intended behavior that terraI18n.config.js is only for non-script use
• OR remove script defaults and let defaults be 'hidden'
• OR remove aggregrate-translations script.

We should land on a consensus before v5 is released.

[emilyrohrbough]

These are a lot of changes. It might be worth maintaining a v5 branch for this work to keep PRs manageable. For example: toolkit-v5...toolkit-v5-remove-nightwatch.

[emilyrohrbough]

Recent changes to aggregate-translations script added the exclude key to open up the default translations search. It was proposed to drop the directories key, but it was kept for passivity. We should explore if the directories key should be dropped. I think at this point it is "dead". #206 (comment)

[bjankord]

In our meeting on Friday, March 15th, we talked about turning terra-toolkit into a monorepo.

Not sure if this GitHub issue is the best to comment on or if a new issue should be logged for the terra-toolkit monorepo concept.

I'd like to see the code in this repo split into 3 packages:
terra-toolkit (the testing part of the current repo)
terra-webpack (the webpack config part of the current repo)
terra-aggreage-translations (the aggregate-translations part of the current repo)

With the idea of terra-toolkit becoming a monorepo, I'm curious what others think about this proposed split of the current repo.

I'm also curious what others think about some of the other singular repos we have like eslint-config-terra, stylelint-config-terra, browserslist-config-terra, and generator-terra-module. Should we pull those repos under the terra-toolkit repo if we go down the monorepo path for terra-toolkit?

[mjhenkes]

Possibly terra-scripts? We also have our tt-serve and serve static scripts as well as aggregate themes.

[emilyrohrbough]

Our toolkit currently has some coupled logic:

I think this breakdown could result in the following mono-repo structure :

/packages
    / eslint-config-terra
    / stylelint-config-terra
    / terra-aggregate-themes
    / terra-aggregate-translations
    / terra-config-webpack
        /config
            - webpack.config.js
    / terra-serve
        /scripts
            - tt-serve
            - tt-serve-static
    / terra-docker
        - docker-compose
        - terra’s base image
    / terra-pack
    / terra-utility
        - Logger
    / terra-wdio
        /scripts
            - tt-wdio
        /config
            - wdio.config.js
            - visual-regression.config.js
        / services
            - Terra Service
                - terra test commands
                - move Axe service implementation here because its coupled logic
                - would like to see Visual Regression Service logic decoupled
            - Service Static Service
            - Selenium Docker Service
            - Service Static Service
                - coupled to serve-static script & webpack version
    / terra-toolkit
        // use to manage versions projects pull in?

One could even argue our custom services could be their own package such that terra-wdio acts as a test config manager instead of implementer potentially.

@mjhenkes I do think terra-scripts or terra-cli package could be appropriate for managing the .bin executables we provide.

[ryanthemanuel]

As long as Terra scripts and Terra utility themselves don’t turn into junk drawers

[ryanthemanuel]

As for issue #257 I propose we drop the script defaults and rely on the defaults in the code later. Thus the fallback goes cli options, config file, and then defaults

[bjankord]

I like the proposal @emilyrohrbough posted. I think decoupling the various features in terra-toolkit is a highly needed improvement. I also see value in terra-scripts or terra-cli package that could be appropriate for managing the .bin executables we provide and dry up the amount of packages within the repo.

In regards to implementation details of the monorepo, I do think using lerna would be good to manage the toolkit monorepo. While a lot of these packages can be standalone, a concern I have is the devDependencies they use. Most of them will share common dependencies, I'm mainly thinking of babel. Being able to hoist the devDependency up and have 1 instance of it would be nice. I believe this should be possible without lerna, but I do think lerna makes managing that easier.

[emilyrohrbough]

We could also create a terra-toolkit package in the mono-repo structure that will house our default peer dependency recommendations and provide an one-to-one out of the box place for people to reference the new packages.

Would need to test this theory, but then we could create set the root-level package.json to "private": true(for example) such that when it is pulled in as a dependency, it will compile & reference/hoist up the package/terra-toolkit so we can have PR validations in terra-core, clinical, and framework before pushing out changes.

Quick reference to other projects that use mono-repos:

• https://github.com/babel/babel/tree/master/packages
• https://github.com/webdriverio/webdriverio/blob/master/packages
• https://github.com/airbnb/enzyme/tree/master/packages
• https://github.com/facebook/react/tree/master/packages