Components: too tightly coupled to dependencies

When using any components, there is no flexibility to use without adding multiple PS packages for styling.

Expected behavior

With BC’s in mind, the components should be as agnostic and lightweight as possible, not requiring or adding a CSS-in-JS library to the depedancy list, but rather using plain CSS. Essentally, a BC should not be required to install core, glamour, or any other dependency, but just download Dropdown and everything works fine.

Actual behavior

If I only need to use Dropdown for example, I cannot just install the single package. It requires the installation of:

• core
• ActionMenu
• glamour
• also adds emotion to bundle

Steps to repro

1. Create a new app using CRA w/ Typescript
2. Install styled-components (example)
3. Install core package
4. Install Dropdown & ActionMenu
5. Run tests (will fail due to no glamour)
6. Run bundle analyze to see emotion is added to bundle
7. Run start to see TS fails due to no typing packages (also no notes on this in the docs)

Related packages

• core@latest
• Dropdown@latest
• ActionMenu@latest

Environment

• OS - MacOS 10.12
• Browser version - Chrome v60

The Value Add

This allows the PSDS to be more flexible and keep all BC bundles as small as possible.

The Tradeoffs

Requires possible rebuild to remove CSS-in-JS lib for pure CSS

[jaketrent]

Hey @caseybaggz , thanks for the perspective. I’ll share a few thoughts that may help as well:

• Packages do have peerDependencies in the case of runtime libraries (eg, react) or packages that must have a single instance in app bundles (eg, glamor, @pluralsight/ps-design-system-theme) or baselines upon which components expect to build (eg, @pluralsight/ps-design-system-normalize).
• core is not a peerDependency at this point and should be included as a dependencies entry where needed.
• CSS-in-JS was chosen (as opposed to CSS stylesheets) so the install story was simpler, not requiring bundler configuration.
• CSS-in-JS was chosen (as opposed to vanilla inline styles) in order to support styles that inline styles don’t (eg, media queries, pseudo selectors and @keyframe animations).
• devDependencies definitely shouldn’t be included in the dist/ output of bundles. If it is, as it seems it might, we need to figure out how to build our packages to exclude that.
• I like your analogy of cars and legos. I’m also a Lego-preferring kind of UI dev. We are also, however, trying to service traditionally fullstack devs who have less UI experience. To this end, we have packaged some things up into larger components. Some times we may have gone too large and complex. And our user base is changing constantly. We need to be more nimble to discover how well the DS is being received and utilized. Your feedback continues to be helpful in this regard.

Thanks for your time and insight!

[jaketrent]

No plans to act on fundamental changes here currently. Will add revisit label as we consider any big-picture changes in the future.