Monorepo

[timkelty]

It's been pretty unanimously decided we should move to monorepo.

The biggest decision is deciding if we want to do fixed/locked versioning or independent: https://github.com/lerna/lerna/#fixedlocked-mode-default

#149
#109

[simonsmith]

So at first glance independent mode seems the most logical to me, as I feel like it makes sense to not confuse people with a major release to say Grid when we actually changed Button. And it follows how the packages have been released so far.

@timkelty Your preference was for the fixed/locked (as do Babel). What's the main reason there? Am I missing a major drawback of independent?

[timkelty]

@simonsmith Yeah independent would be most analogous to how we've been doing things.
I only suggested fixed because its easier to manage.

Your Grid/Button example is a perfect example of the drawbacks. However, one could envision Grid and utils-size benefiting from bumping up together, because of the interplay.

Going fixed ensures that "if you suitcss packages are all on 9.x, they'll all work together". You don't get that same assurance with independent.

So the tradeoff is:

• independent - potentially confusing/meaningless bumps for the end user
• fixed - less assurance that different package versions will work together

No perfect solution. I'm fine with either, really. I think I prefer fixed because our utils/components do interact and prefer the tradeoff of convenience for stability.

[simonsmith]

"if you suitcss packages are all on 9.x, they'll all work together".

Ah I see, that's quite a nice assurance to users.

Thinking about the Grid discussion in the other issue and the possibility of v4 being flex and v5 being css grid, how would we handle publishing fixes to older tags? I presume Lerna makes this easy too?

[timkelty]

I presume Lerna makes this easy too?

Good question. Haven't done that yet. Seems like we might want to have branches for majors (4.x, 5.x), so you can jump between them easily to release bumps.

At that point if you on your 4.x branch and lerna publish a patch, it should just push a patch release for 4.x (since its just looking at the package.json version)

[timkelty]

If we go with fixed - I think we'll prob want to do what babel did when they converged - take the highest version of any of the independent packages (which unfortunately would be v14 from stylelint-config-suitcss, but oh well) and do a major bump from there for everything. So the latest "monorepo" version of all packages would be v15 and sanity would start from that point onward.

[simonsmith]

Okay, that makes sense.

Thinking more on the fixed approach and Babel. I notice that they still do big bang releases (it gets posted all over reddit, twitter etc) so for example Babel 7 is meant to be the next big release. But does this mean that they conveniently never had to publish a major release in any of their dozens of plugins? Or are they holding back major changes as a group so as not to go to say Babel 9 just because one plugin had two changes?

That would be my concern about fixed

[timkelty]

No I think they do hold back changes that would be breaking, to keep a sane major release history, so that's another drawback.

Ya know, talking this over theres probably no harm in starting in independent mode, as it would be the least friction. We can always decide to go fixed later.

[simonsmith]

Ya know, talking this over theres probably no harm in starting in independent mode, as it would be the least friction. We can always decide to go fixed later.

I think you're right. If we can get all the current packages on Lerna that's the bulk of the work done and we can see how it goes

[simonsmith]

Created a branch here with independent settings and lerna bootstrap applied - https://github.com/suitcss/suit/tree/lerna

Main thing to try now is to publish a package change on this branch I think. So that will basically create a git tag and publish to npm.

@giuseppeg I know you've had experience with this on your suitcss-toolkit repo. If I make a change to one package now and hit lerna publish it will ask what I want to bump each package to.

I understand this is correct behaviour but does that mean each time I try to publish one package change I have to bump every other package?

It doesn't seem to give me an option to not bump.

[giuseppeg]

@simonsmith I suppose that those depend on the package that you are trying to publish right? In that case there is not much you can do, except for changing policy and pin dependencies i.e. avoid ranges ^. Maybe you can use this https://github.com/lerna/lerna/pull/707/files#diff-a3895371e2b1cc1923cc44b0f317c41cR170 :) but it might be risky and not a canonical way to work around this issue (you may want to read the issue that the PR is fixing).

if you suitcss packages are all on 9.x, they'll all work together

While this is true imo it makes upgrading less likely to happen since multiple packages might introduce breaking changes and one has to figure out which. Dealing with one breaking change at the time is easier and allows for more frequent upgrades.

[giuseppeg]

--scope and --ignore exist for this purpose. You can also manually pin a version range (which is what I would generally do).

[simonsmith]

@mlnmln

Did you use lerna import?

No, I just took the repos as folders. I hadn't seen lerna import! Looks like that might do a better job!