The Polaris one seems great for calling out recent changes and sending appreciation for contributors.

Some ideas for topics:

• New libraries and major versions
• New documentation
• Sewing kit updates
• Team working on
• Updates about Shopify Web
• Thanks to contributors
• Call for help
• Pretty header like Polaris

• When to use and when not to
• How to structure reducers/ action creators

https://astexplorer.net/#/gist/a546003dbca6f7d2f1e581a93c590de8/7d22d9807cf1dc033f941c5932a7104c28562f16

// Component exists in Polaris. Import Modal Stack Button List from @shopify/polaris (at 8:1)
   import {Modal, Button, List, Stack} from '@shopify/polaris-next';
// ^

// Component exists in Polaris. Import Modal from @shopify/polaris (at 9:1)
   import {Modal, NewComponent, NewComponent2} from '@shopify/polaris-next';
// ^

If I open a debug session inside babel-preset-env, I see that IE 10 is always included in the final list of target platforms:

The last 2 versions part of our config overrides ie >= 11. Confirmed by the online browserlist calculator:

I think the main difficulty here will be that the entrypoints currently have side-effects on being required. I'm not sure of a good way to handle that in tests.

The possibility has also been discussed that we should instead just strive to make them substantially simpler (mostly by moving stuff into the app component).

Most notably:

• on<Verb><Noun> versus on<Noun><Verb>
• show<Noun> versus <noun>Visible

Should include a way to associate errors, ideally.

We've been moving away from these because we have a different construct (types) that allow us to ensure the right data is passed around, and it makes things easier to test/ more decoupled.

• Deferred rendering by passing a renderer into a component, and only calling for some data
• When to use PureComponent/ Component/ custom shouldComponentUpdate

Right now, anything that is shared between them needs to be in app/*. This is annoying for things like utility functions, which could easily be shared with the server. It might be that this is only a problem because these things should be shared packages, but we should make sure that will actually be enough.

There should be a https://github.com/Shopify/eslint-plugin-shopify/blob/master/docs/rules/no-debugger.md

Linting tests are easy to write (although they can take a bit of time!). They are needed if we want to continue distributing this config at scale while iterating on it.

In case someone wants to give it a go, here's an example of a test suite here (using Jest): https://github.com/salesforce-ux/stylelint-config-slds

• Rails app
• Node app
• Component-ey packages
• Regular packages

This is a pattern we see fairly often that will always bite us at some point: setting state after an async operation:

doSomething().then(() => this.setState({done: true}));

// or

await doSomething();
this.setState({done: true});

This is because, unless the operation is completely synchronous, the delay of getting to the setState could be enough for the component to have unmounted. We should warn about these unless they are nested in some kind of condition (this is probably a trickier flow analysis-requiring rule to write).

I've run in two issues recently where we were relying on constructor.name to do things. See:

• https://github.com/Shopify/shopify/pull/145754
• https://github.com/Shopify/payment-sheet/pull/986

The problem is that since the JS is uglified, it didn't work in production while it worked in dev shops.

We have 2 options:

1. Setting Uglify keep_fnames option to true
2. Write a custom linter to prevent that

I'm for option 2. What do you think people?

cc @lemonmade

• Markup
• CSS
• JavaScript

Maybe also link out to the Ruby one?

Once these guides are moved to this repo, links to them should be removed from the Vault.

There are about 6 files that need to be edited.

https://github.com/konstantin24121/stylelint-performance-animation

I propose the following, based on our seeming consensus on the web foundations team around type-safety:

1. Principle doc -> Compile-time over run-time failures
2. Decision doc -> Use TypeScript as our type-safety mechanism for web projects

Thoughts? @TheMallen @lemonmade

I'd be happy to contribute a PR with these docs

For components/Component/index:

export {
  default,
  Props,
  ...
}  from './Component';

(please no glob export, that makes it harder to reason about what you are actually exposing)

For components/index:

export {
  default as Component,
  Props as DefaultProps,
  ...
} from './Component';

Related issue in web: https://github.com/Shopify/web/issues/5237

Problem

Marketing projects use different babel presets as seen here. Right now, this needs to be copied to different marketing projects.

Proposal

Add marketing specific configuration to babel-preset-shopify.

Syntax

{
  "babel": {
    "presets": ["shopify/marketing"]
  }
}

or

{
  "babel": {
    "presets": [
      ["shopify/web", {"type": "marketing"}]
    ]
  }
}

https://github.com/eslint/eslint-plugin-markdown

There could be a number of checks:

• Move our ESLint overrides down to the section level (document why this is the standard), and check for excessive overrides
• Associate errors to sections within Bugsnag
• Presence of a file that outlines the owner of a particular section

We have code for

'no-catch-shadow': 'error'

in our eslint config, but this rule is deprecated and throws an obscure error when argless catch clauses are used.

Since we don't need to support IE8, perhaps we can 🔥 this one? cc @lemonmade

• app/icons versus section-/ component-specific folders
• Naming of the folder it is in (and why)

https://github.com/Shopify/web/issues/1759

• Single assertion per test
• When to use custom matchers
• How to deal with global mocks
• Factories versus beforeEach/ afterEach
• Mocking subcomponents
• Triggering props
• Patterns to avoid testing state

• Class naming
• Variation on top, descendant selectors to subcomponents

We have to be thorough when upgrading dependencies. In order to democratize this process, we should provide a clear contribution path for those (like me) who wish to help.

• Mention steps / requirements for dependency updates
• Provide a template for each added rule (e.g. following the same outline as below)

- **eslint-config-prettier:** [`v2.6.0...v2.9.0`](https://github.com/prettier/eslint-config-prettier/compare/v2.6.0...v2.9.0)
  - Added: The [implicit-arrow-linebreak] rule
  - Added: The [react/jsx-one-expression-per-line] rule.
  - Added: The [lines-around-comment] rule (as a [special
    rule][lines-around-comment-special]).
  - Added: The [no-unexpected-multiline] rule (as a [special
    rule][no-unexpected-multiline-special]).

• Require a changelog update
• For important/breaking changes: require the upgrade path to be documented

Do you see anything else? cc @GoodForOneFare @ismail-syed @lemonmade