[Emotion] Improve checklist/QA process

[cee-chen]

Summary

• Adds the entire Emotion conversion checklist to our default PR template (with extra details + categorization) to encourage devs to fill it out fully
• Adds an Emotion conversion prompt/template to our changelog yo generator for better consistency

Feedback would be appreciated on the PR template md file (tagging multiple reviewers for that purpose). Are items well categorized? Would you know how to know if a step should or shouldn't be done with just the information provided, or is more context needed?

QA

Remove or strikethrough items that do not apply to your PR.

General checklist

• Checked in both light and dark modes
• Checked in mobile
• Checked in Chrome, Safari, Edge, and Firefox
• Props have proper autodocs and playground toggles
• Added documentation
• Checked Code Sandbox works for any docs examples
• Added or updated jest and cypress tests
• Checked for breaking changes and labeled appropriately
• Checked for accessibility including keyboard-only and screenreader modes
• Updated the Figma library counterpart
• A changelog entry exists and is marked appropriately

Emotion conversion checklist

• Does it work?
• Output CSS matches the previous CSS / as expected in browsers
• Rendered className reads as expected in snapshots and in browsers
• Checked component playground (class components wrapped in withEuiTheme need to pass true as the second argument to its propUtilityForPlayground in src-docs/src/views/{component}/playground.js)
   
• Unit tests
• shouldRenderCustomStyles() test was added and passes with parent component and any nested childProps (e.g. tooltipProps)
• Removed any mount()ed snapshots in favor of render() or a more specific assertion
   
• Sass/Emotion conversion process
• Converted all global Sass vars/mixins to JS (e.g. $euiSize to euiTheme.size.base)
• Removed or converted component-specific Sass vars/mixins to exported JS versions, listed removals in changelog, and ran yarn compile-scss to update JSON files
• Simplified calc() to mathWithUnits if possible (if mixing different unit types, this may not be possible)
• Added an @warn deprecation message within the global_styling/mixins/{component}.scss file
• Removed component from src/components/index.scss
• Deleted any src/amsterdam/overrides/{component}.scss files (styles within should have been converted to the baseline Emotion styles)
   
• CSS tech debt
• Reduced specificity where possible (usually by reducing nesting and class name chaining)
• Wrapped all animations or transitions in euiCanAnimate
• Used gap property to add margin between items if using flex
• Converted side specific padding, margin, and position to -inline and -block logical properties (check inline styles as well as CSS)
   
• DOM cleanup
• Did not remove any block/element classNames (e.g. euiComponent, euiComponent__child)
• Deleted any modifier classNames or maps if not being used in Kibana. Before doing this step:
  • Search/grep through Kibana's codebase for {euiComponent}- (case sensitive) to check for source code usage of modifier classes
  • If usages exist, consider converting to a data attribute so that consumers still have something to hook into
     
• Kibana due diligence
• Pre-emptively check how your conversion will impact the next Kibana upgrade. This entails searching/grepping through Kibana (excluding **/target, **/*.snap, **/*.storyshot for less noise) for eui{Component} (case sensitive) to find:
• Any test/query selectors that will need to be updated
• Any Sass or CSS that will need to be updated, particularly if a component Sass var was deleted
• Any direct className usages that will need to be refactored (e.g. someone calling the euiBadge class on a div instead of simply using the EuiBadge component)
   
• Extras/nice-to-have
• Documentation pass:
  • Converted any remaining .js docs files to TS
  • Misc cleanup of docs code (e.g. combine imports to single from '../src', replace <React.Fragment> with <>)
• Check for issues in the backlog that could be a quick fix for that component
• Optional component/code cleanup: consider splitting up the component into multiple children if it's overly verbose or difficult to reason about

[cee-chen]

jenkins test this

[kibanamachine]

Preview documentation changes for this PR: https://eui.elastic.co/pr_6294/

[miukimiu]

Feedback would be appreciated on the PR template md file (tagging multiple reviewers for that purpose). Are items well categorized? Would you know how to know if a step should or shouldn't be done with just the information provided, or is more context needed?

The items are well categorized and I would know if a step should or shouldn't be done with just the information provided. So it LGTM! 👍🏽

For me, the only boring thing when I'm going through the checklist is to strikethrough. Removing items eliminates the context of what doesn't apply. So I always prefer to strikethrough. But I wonder if anyone has an alternative to the strikethrough.

[1Copenut]

Thank you for putting this thorough update together @constancecchen. My comments about linking or bracketing functions stem from things I've done or looked up while working on conversions. LMK if anything is unclear or changes don't make sense in terms of the checklist.

[cee-chen]

This was super helpful, thanks y'all! PR feedback should be addressed in the latest commit - let me know if not!

[1Copenut]

👍 Much appreciated!

[cee-chen]

Sorry, I totally forgot to respond to Elizabet's top level comment!

For me, the only boring thing when I'm going through the checklist is to strikethrough. Removing items eliminates the context of what doesn't apply. So I always prefer to strikethrough. But I wonder if anyone has an alternative to the strikethrough.

I honestly don't mind either way if people remove vs strikethrough. For myself when I do strikethroughs it's really for me to consciously say "this doesn't apply to this PR" or "I deliberately did not do this step". For more simple PRs I do just go ahead and remove steps instead - I totally agree striking through line by line is tedious 😅 I do wish GitHub had a handy keyboard shortcut for strikethrough... it looks like they don't though 😩

[kibanamachine]

Preview documentation changes for this PR: https://eui.elastic.co/pr_6294/

[cee-chen]

@elastic/eui-design Going to leave this open until EOD Pacific for comments and then merge this in before I go out on leave. We can always continue tweaking the template as needed!

[kibanamachine]

Preview documentation changes for this PR: https://eui.elastic.co/pr_6294/