Monorepo about suit HOT 25 OPEN

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

from suit.

@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!

from suit.

I agree that the first step would be to reorganize the org and make a monorepo but I also don't have time to do this right now.

@mlnmln in case you have time and want to give this a stab it'd be nice to also evaluate Bolt https://github.com/boltpkg/bolt (see if it is maintained and if it is missing any important feature that lerna has). I'd be fine to go with lerna right away too though - in any case if you do this please add a tl;dr section to the README to explain how to manage the repo with that specific tool (the last thing I want is make it harder to contribute).

@giuseppeg

I have no experience with bolt, so my gut reaction is to stick with lerna as a default, stable and proven solution. Do you see any compelling advantages of using bolt over lerna?

from suit.

Some epic work there @mlnmln

I might need a couple days to get time to read through and review it all, but I will asap

from suit.

Have moved all existing open issues to this repo. Will look at the README changes so we can get new versions published.

Next step will be to then archive the old repos

from suit.

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?

from suit.

@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.

from suit.

"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?

from suit.

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)

from suit.

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.

from suit.

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

from suit.

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.

from suit.

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.

from suit.

@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.

from suit.

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

from suit.

@mlnmln no worries, lerna should be fine. Do you have an idea of what features of lerna do we need? I am asking because in theory we could even use yarn workspaces to manage the dependencies and a little script to release the packages (example).

from suit.

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?

@simonsmith Initially you have to bump each package, since they are tracked as changed by lerna. Further updates in a single package won't force updates in the others when using independent mode. Also it is possible to ignore files from triggering a change, e.g. if typos in docs are updated etc, this is what babel uses.
https://github.com/lerna/lerna/tree/master/commands/version#--ignore-changes
https://github.com/babel/babel/blob/master/lerna.json#L16

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.

Lerna docs recommend creating git tags in the master branch only. https://github.com/lerna/lerna/tree/master/commands/version#--allow-branch-glob

from suit.

@mlnmln no worries, lerna should be fine. Do you have an idea of what features of lerna do we need? I am asking because in theory we could even use yarn workspaces to manage the dependencies and a little script to release the packages (example).

@giuseppeg core features from my experience are just

• lerna bootstrap
• lerna publish
• lerna version

But

• lerna run (run st. in each package, e.g. test)
• lerna add(add a dependency to each package)
• lerna link convert (hoist dependencies to file://)
• lerna import (import existing repos with commit history into packages)

are very useful and timesaving.

lerna can be configured to work with yarn workspaces as well.
https://github.com/lerna/lerna/blob/master/commands/bootstrap/README.md#--use-workspaces

from suit.

Added a working state in a PR, please let me know what you think.

Please note that the following topics are not part of it intentionally:

• Preserving paths to "binaries", https://github.com/lerna/lerna#common-devdependencies, currently you still need to run yarn install in most packages if you want to execute yarn test successfully.
• Moving to org ('@suitcss/'). This can/should be done in a later stage imo.
• Moving suit itself to its own package. I was unsure about this and wanted to align with you guys before doing anything here. My take is that it would be consistent and then the root package here would only contain lerna and the shared dev dependencies in the end.
• Moving shared dev dependencies out of each package into root.
• Moving to yarn. After reading on #147 I'm assuming it's ok to move to yarn during the migration process. However the npm scripts and docs need updates as well. Also we might not want to store lock files at all. https://github.com/babel/babel/blob/master/lerna.json#L34

I would recommend tracking those in individual issues.

from suit.

#153 is now merged!

Should we bump all the packages on npm so they get revised package.json information (e.g repo link)? If so, is a patch sufficient?

Also, thoughts on the existing repositories? I was thinking move any existing issues to this repository and then either archive them or move them out of the org to reduce confusion

from suit.

Should we bump all the packages on npm so they get revised package.json information (e.g repo link)?

I think we can wait until we have fixed the README files at least.

I was thinking move any existing issues to this repository and then either archive them or move them out of the org to reduce confusion

Yup agreed! We should figure out how to import the issues in bulk and maybe figure out a sane way to manage them eg. labels or issue templates (or just title scheme).

from suit.

Looking at the packages/ folder now. Would it make sense to make subfolders like packages/<components|utils>. Does Lerna support this?

from suit.

Package location can be configured in lerna.json, so this should work.
https://github.com/lerna/lerna#lernajson

We might run into unforeseen issues if we have multiple, different paths in the future though. Would need investigation.

from suit.

I suggest you look for something better supported and replying on PostCSS. Just face it, postcss won the race. Check out Visual Components Library VCL for which we also have an Angular library and plan a Web Components Library as well.

from suit.

The work done on suitcss is genius. If we all speak the naming convention language roughly we can start creating an eco system of components and are easily themeable, interchangeable, and easy to learn from. The goal should be to have all of us create components and utilities that can easily be combined into a greater whole. SuitCSS has all the underpinnings of this.

from suit.