Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Primer monorepo #230
Moving Primer into a monorepo
This pr works towards moving the source files for Primer back into the Primer org, to be pulled into GitHub via npm. More context on this decision here, and here's an interesting post on why Babel is a monorepo.
@primer/design-systems @muan @josh @mislav What other things do I need to take into account? Any questions, concerns? Let me know if you have any thoughts on using Lerna and Semantic Release—they look like good options and help us with some of our maintenance and publishing workflow issues. I'll need help once this is ready with switching GitHub over to pulling this in a dependency.
So excited for the new setup!
I think they should have their own ones since each package can be installed separately. User will need both files when they are using just one package.
IMO this doesn't give us huge wins since
With normal one-to-one repo/npm packages, you would be able to just install from source without a release. Like
Also it looks to me that packages aren't versioned individually for React, Babel, and Jest, and I can't find
Thanks @muan for the feedback! Replies below but also going to follow up with a comment re breaking this up a bit since not everything is essential for the first ship to make this a mono-repo.
The value of semantic release seems to be removing the human element from making decisions about version changes. Folks incorrectly bumping the version number has been a continuous issue, I think due to a combination of personal opinion, being unfamiliar with Semver, or because mapping CSS changes to Semver isn't always obvious. I'm going to leave this til later though as I agree that it's not essential to shipping this pr, and Lerna will stop us bumping a minor or major number and forgetting to reset the patch to 0.
I'd like to chat with you about this. I suggested this since I thought was a normal/best practice since it keeps the distribution via npm and allows you to share with the open-source community for testing. Maybe this isn't necessary for us, but want to make sure it's easy for all GitHub teams using Primer. This will increase over the next year as more non-dotcom sites move over to Primer so whatever we do we need to make sure it's easy to communicate and test updates.
Not without spending some time searching around, no. But it doesn't matter to me that those projects aren't individually versioning their packages, it's a supported feature of Lerna and seems like the right thing to do for us, and it maintains our current versioning system. It makes it easier to push individual updates more safely since folks using it will be able to specify what they're ready to update to. I.e. if we updated our button styles and our box styles, but box styles would cause a lot of work for a team to update to, they'd still be able to pull in the new button styles and only update their box styles when they had the time to. If we weren't using Lerna I'd still want to set the repo up this way, Lerna just makes it easier.
Also re working on this in dev (in case that's what you were curious about), Lerna handles symlinking and when we run the bootstrap script it will look at the changes logged in git and ask us what we want to bump the version number too automatically. So having individually versioned should be fine. I'm testing this in a another repo before blowing everything up here so will see how it goes!
Sorry, I'm not doubting if we should do this, but asking what does this set up look like in real life. We should 100% version them separately.
@shawnbot Here's the error I'm getting:
This was after I updated the marketing package to include the import for
I thought maybe it was just having an issue with previous versions of how the module were setup, so I ran
I manually removed the node modules and tried this all over again, to no avail. I've tried manually installing packages and I tried this with and without lockfiles. I started to look through issues in the Lerna repo, and found that lerna isn't compatible with npm @5, which I am on. So that may be why I'm getting a bunch of issues
Here's a quick update, which I also posted to Slack. In case it matters, I'm running Node v8.1.2 and firstname.lastname@example.org. I ran
First, I looked at the
This prompted me to confirm the new versions for both the
This completed without any errors and produced the following diff:
diff --git a/packages/primer-css/package.json b/packages/primer-css/package.json index 4cd021d..77eb2ef 100644 --- a/packages/primer-css/package.json +++ b/packages/primer-css/package.json @@ -2 +2 @@ - "version": "7.0.0-6", + "version": "7.0.0", @@ -25 +25 @@ - "primer-marketing": "^4.0.0-5", + "primer-marketing": "^4.0.0", diff --git a/packages/primer-marketing/package.json b/packages/primer-marketing/package.json index 234ed48..a66041a 100644 --- a/packages/primer-marketing/package.json +++ b/packages/primer-marketing/package.json @@ -2 +2 @@ - "version": "4.0.0-5", + "version": "4.0.0",
There are also new (to git)
While surfing around for more info, I discovered a couple of things:
And now, off to the screen hero!
Jun 23, 2017
referenced this pull request
Jun 23, 2017
I guess this is rather late but I can answer questions y'all might have about Lerna (I maintain Babel and Lerna somewhat). Not sure how well it works with npm 5 and hoisting since never looked into it, but does seem like everyone did their research pretty well
FYI I saw this via github/opensource.guide#404 so not just randomly commenting on issues
Thanks @hzoo! I had joined the lerna slack but @shawnbot ended up helping me solve the issues we were having. There's some follow up work to do on our side and there's some feedback we'll pass on to the you and the Lerna maintainers if issues haven't been opened already.
I don't think the problems we hit were really npm@5 issues, however it didn't seem to like the lockfile. Either way, since there are so many bug reports for npm@5 at the moment, it seems sensible to stick with 4 for now.
Also, you're more than welcome to randomly comment on our Primer pr's