Rename package to @primer/primitives

[BinaryMuse]

This PR implements the move away from a monorepo and consolidation under @primer/primitives as described in #8.

• Create @primer/primitives package at root
• Remove lerna
• Make old modules available at @primer/primitives/<module>
• Add deprecation warnings to old npm packages (do this after @primer/primitives is published)
• Update README and other documentation as appropriate

Fixes #8

[BinaryMuse]

@shawnbot I think the changes here would pretty much do it. I did have one thing I wanted to ask you about: in order to have, e.g., @primer/primitives/typography as a possible import, we need to either have top-level folders (/typography, /spacing, etc) at the top level of the repo, or we need to switch so that we "build" the data into a dist/ folder that has the structure we want. I'm personally fond of not having to depend on a build step, but also not a fan of having all these loose top-level folders (and we'll need to add more for any additional categories we add). Thoughts? 💭

(Edit: another thought I had was making the main import @primer/primitives and the others something like @primer/primitives/modules/typography)

[shawnbot]

A couple of thoughts:

1. I like the brevity of import '@primer/primitives/spacing', so I think we should make that possible via either /spacing.js or /spacing/index.js (I prefer the latter).

2. The only build step I'd expect to need is one that serializes each of the endpoints as JSON for other languages to consume. So our build step could serialize /spacing/index.js as /spacing.json, for instance.

3. I feel like there's a disconnect between the words "primitives" and "theme" here, the latter being more specific. IMO, we should either:

   • Have index.js export colors, spacing, and typography so that the named exports match the individual entrypoints (import {spacing} from '@primer/primitives', instead of import {space}), then have a separate theme export (i.e. @primer/primitives/theme → theme.js) that conforms to the theme-ui spec; or...

   • Publish a separate @primer/theme package that does the theme-ui thing.

I'm interested to hear what @emplums and @broccolini think too!

[BinaryMuse]

I think I get where you're coming from. Although:

2. The only build step I'd expect to need is one that serializes each of the endpoints as JSON for other languages to consume

Since the files are already JSON, is there anything we would need to do at all?

[shawnbot]

Since the files are already JSON, is there anything we would need to do at all?

Sorry, I don't know why I imagined them as JS. So yeah, no changes needed on that front! 😊

[emplums]

This looks good to me! I agree it's nice to have the theme as a separate export and fine with having different folders for each subfolder vs adding that as a build step!

[BinaryMuse]

I agree it's nice to have the theme as a separate export

Cool, I like this as well. As I'm implementing these changes, all of the following are supported:

import theme from '@primer/primitives/theme'
import colors from '@primer/primitives/colors'
import typography from '@primer/primitives/typography'
// ...
import { theme, colors, typography } from '@primer/primitives'

The more I mess around with it, the more I'm in favor of exporting both theme and each of the other items (colors, typography, etc.) on the top-level object and not allowing the imports from @primer/primitives/<whatever> — it feels to me like it creates an additional API contract we have to maintain for no great benefit (since the import/require syntax works so well with destructuring already). But this opinion is fairly weakly held and I could be convinced pretty easily. :)

[shawnbot]

The more I mess around with it, the more I'm in favor of exporting both theme and each of the other items (colors, typography, etc.) on the top-level object and not allowing the imports from @primer/primitives/<whatever> — it feels to me like it creates an additional API contract we have to maintain for no great benefit (since the import/require syntax works so well with destructuring already). But this opinion is fairly weakly held and I could be convinced pretty easily. :)

I'm totally on board with this. +1000 to fewer contracts to maintain!

[BinaryMuse]

Sweet — in that case, the README is updated and this should be good to go.

[shawnbot]

Looking great! Let's ship this!

[emplums]

Wooooo!!! 🚢 it! 🎉