Jss: Mono Repo and NPM org

[HenriBeck]

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:

• jss
• react-jss, styled-jss and aphrodite-jss
• all of the currently provided plugins by Jss

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

• jss -> @jss/core
• react-jss (integrations) -> @jss/react
• jss-expand (plugins): @jss/plugin-expand

[oliviertassinari]

I can only approve the idea 👍

[TrySound]

And this will solve the problem of reusing builder.

[kof]

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

On Sat, May 19, 2018, 19:05 Bogdan Chadkin [e-mail] 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]

So do we go with proposed jss scope?

[kof]

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 [e-mail] 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]

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]

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]

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

[kof]

@HenriBeck are you up for this?

[HenriBeck]

yes, will start on the weekend

[HenriBeck]

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

[kof]

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

[HenriBeck]

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

[kof]

yes, immediately after release

[kof]

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

[HenriBeck]

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

[kof]

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

[kof]

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]

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]

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

[TrySound]

A have a couple of improvements before release.

[HenriBeck]

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]

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]

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

[kof]

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

[HenriBeck]

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]

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]

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]

Do we delete the old changelogs then?

_{Sent with GitHawk}

[kof]

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]

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]

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

[kof]

I think everything that lands in monorepo, yes

[HenriBeck]

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

[TrySound]

Maybe just titles with references?

[kof]

There are tools for moving issues, we can automate it

[HenriBeck]

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

[kof]

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