cssinjs / jss

JSS is an authoring tool for CSS which uses JavaScript as a host language.
https://cssinjs.org
MIT License
7.06k stars 397 forks source link

Mono Repo and NPM org #714

Closed HenriBeck closed 5 years ago

HenriBeck commented 6 years ago

I would like to propose to move the whole Jss project into a Lerna mono repo like babel and other projects did. I would also then move to a fixed mode for the versioning (like babel). This would also solve some problems with maintaining all of the dev dependencies of the repositories.

This would include the following repositories:

Another idea would be to create npm organization and publish most packages under this organization.

oliviertassinari commented 6 years ago

I can only approve the idea 👍

TrySound commented 6 years ago

And this will solve the problem of reusing builder.

kof commented 6 years ago

I would need someone to commit finishing this migration, who can?

On Sat, May 19, 2018, 19:05 Bogdan Chadkin notifications@github.com wrote:

And this will solve the problem of reusing builder.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/cssinjs/jss/issues/714#issuecomment-390418667, or mute the thread https://github.com/notifications/unsubscribe-auth/AADOWG9rqzXwroG9baFFwYEee2x11xlwks5t0FDygaJpZM4T93gj .

TrySound commented 6 years ago

So do we go with proposed jss scope?

kof commented 6 years ago

Not sure if react-jss, aphrodite-jss and styled-jss should be part of the monorepo. But plugins + core could be monorepo for sure.

On Sat, May 19, 2018, 21:15 Bogdan Chadkin notifications@github.com wrote:

So do we go with proposed jss scope?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/cssinjs/jss/issues/714#issuecomment-390426445, or mute the thread https://github.com/notifications/unsubscribe-auth/AADOWCmdeN_rZAhNpbahsCxKO1UYyZggks5t0G9tgaJpZM4T93gj .

HenriBeck commented 6 years ago

I would also include the provided integrations from the jss team in the monorepo. That way we could easily share code between them as well (Updating styled-jss to use the same JssProvider for example).

I could migrate it, but I won't have time before next week.

kof commented 6 years ago

After next week is fine, just need to be sure we can finish it and not leave it in a half migrated state for months.

The reason I am not sure I would put them all into monorepo is because they have partially different setup, separate issue trackers and it feels like they are entirely separate projects.

We need a clear decision framework. One possibility: everything that depends on JSS core, should be part of the monorepo, everything else - not.

kof commented 6 years ago

Ok, we got merged the first pr towards monorepo, now we need to move plugins to it

kof commented 6 years ago

@HenriBeck are you up for this?

HenriBeck commented 6 years ago

yes, will start on the weekend

HenriBeck commented 5 years ago

All of the plugin repos are now imported. Any other repos that should be imported?

kof commented 5 years ago

I checked, all plugins are here, is there anything else that is topping us from jss 10 release?

HenriBeck commented 5 years ago

I think we should need to archive the plugin repos and add a message to the readme.

kof commented 5 years ago

yes, immediately after release

kof commented 5 years ago

oh btw. we should check all the docs and fix the links to old repos

HenriBeck commented 5 years ago

Yeah, we need to update the links in the package.json files

kof commented 5 years ago

also mb add docs regarding esm builds? and generaly whats in the dist?

kof commented 5 years ago

Btw. the site was getting the docs for plugins from each repo, we could fix the site to the new repos as an intermediate step or we could move all markdown files from each plugin repo to the main docs dir and fix the site to use this one. In any case once we archive old repos, we need to fix the site.

kof commented 5 years ago

Also I am wondering if babel plugin should be part of this release or a separate, it would be a minor version number in any case, but mb it should be one big announcement

kof commented 5 years ago

@HenriBeck are you on twitter? (if you want to be mentioned in the announcement)

TrySound commented 5 years ago

A have a couple of improvements before release.

HenriBeck commented 5 years ago

Is the babel plugin ready? I think we should test it to actually be ready when publishing.

We should also write a migration guide.

I'm on twitter but nonactive.

kof commented 5 years ago

babel plugin its def. not ready yet, yeah we should actually take more time for testing …

migration guide for babel plugin? Docs on my todo list, evtl even an article. But migration guide is not needed.

Unless you mean because of packages and esm. What are the points user should know?

HenriBeck commented 5 years ago

Yes, I don't mean a migration guide for the babel plugin. It's mostly about the package names.

kof commented 5 years ago

I think package names is too trivial to write a migration guide, a few more notes in the changelog should be enough.

HenriBeck commented 5 years ago

Okay, do we continue to use the changelog in the different packages or are we going to have one global changelog

Sent with GitHawk

TrySound commented 5 years ago

I think we should have a single changelog to simplify maintaining. Babel team structured it quite well and not verbose. https://github.com/babel/babel/blob/master/CHANGELOG.md

kof commented 5 years ago

Good question, looking into babel its a single root changelog. I think it makes sense with monorepo and probably akes it easier for the user

HenriBeck commented 5 years ago

Do we delete the old changelogs then?

Sent with GitHawk

kof commented 5 years ago

In theory we should move them all into the main changelog in the right order, but since it is a bit of work, I am not sure its worth it to do it chronologically.

Mb lets just add a section below the main changelog: "## Plugins changelog prior to v10" and just paste them all one by one?

And remove them from the plugins repos

HenriBeck commented 5 years ago

Or we just remove them without merging? They still exist in the old plugin repos.

EDIT: That way we could also publish the global changelog with every package.

HenriBeck commented 5 years ago

Also, what do we with the integrations? Should I import them as well?

kof commented 5 years ago

I think everything that lands in monorepo, yes

HenriBeck commented 5 years ago

We will need to import/move the issues then as well

TrySound commented 5 years ago

Maybe just titles with references?

kof commented 5 years ago

There are tools for moving issues, we can automate it

HenriBeck commented 5 years ago

https://github-issue-mover.appspot.com/

kof commented 5 years ago

I used zenhub before, but this seems fine as well … whatever works.