feat(dropdowns): migrate react-dropdowns to Typescript

[austingreendev]

Description

This PR is a redo of #369 😄

There have been some changes recently in the typescript parser that makes sticking with styleguidist more feasible than before.

For our components it's common for us to spread attributes to their semantic component. This is possible to type, but results in:

interface IButtonProps extends HTMLProps<HTMLButtonElement> {
  ourCustomProp: boolean;
}

For automated prop generation this would show all 1000+ valid props, including our custom ones.

The react-docgen-typescript module has added some helpers for this where I can filter out any props coming from node_module libraries (like React in this case).

Detail

Same as #369, but without Storybook.

The first commit is only the TS additions to the build and test infrastructure. The second is migrating dropdowns to TS.

The examples and component/testing logic have been left unchanged in this PR.

Checklist

• 👌 design updates are Garden Designer approved (add the
  designer as a reviewer)
• 💅 view component styling is based on a Garden CSS
  component
• 🌐 Styleguidist demo is up-to-date (yarn start)
• ⬅️ renders as expected with reversed (RTL) direction
• ♿ analyzed via axe and evaluated using VoiceOver
• 💂‍♂️ includes new unit tests
• 📝 tested in Chrome, Firefox, Safari, Edge, and IE11

[coveralls]

Coverage increased (+0.5%) to 95.246% when pulling 63d6b02 on agreen/typescript-v2 into 9cf426b on master.

[jzempel]

Lgtm! Can you comment on the Travis script reordering?

[austingreendev]

Can you comment on the Travis script reordering

Yes! This is due to typescript needing the type definitions in the nested packages node_modules. Specifically downshift and react-popper for this package.

Moving the lerna bootstrap earlier in the process ensures that all the modules (and their types) are available.

[fodier]

I’m curious @Austin94, why do you prefer to use babel-loader (with @babel/preset-typescript) instead of ts-loader (or ts-loader + babel-loader without @babel/preset-typescript)? What would you lose?

And a related question: have you tried to emit declaration files at the same time as when compiling TS?

Glad to see this PR by the way 😃.

[austingreendev]

why do you prefer to use babel-loader (with @babel/preset-typescript) instead of ts-loader (or ts-loader + babel-loader without @babel/preset-typescript)?

This matches the default webpack config that exists in create-react-app now.

have you tried to emit declaration files at the same time as when compiling TS?

This got me thinking about the webpack ordering and I've reconsidered the ts-loader vs @babel/preset-typscript decision.

I've now updated the build to use ts-loader -> babel-loader and emit those declarations during the build step. This should increase the build speed over time as we move more packages over.

[ryanseddon]

LGTM

[ryanseddon]

Why the separation here for tsx into two different loaders?

[austingreendev]

This loader uses enforce: 'pre' which I believe has to be enforced at a module rule level. We don't want to enforce that on ts-loader and babel-loader