Monorepo initial configuration

[zalmoxisus]

I made a minimal implementation for the monorepo with lerna and using yarn workspaces, added scripts to run linting and tests inside packages, and for publishing. Probably would be great to have the same linting rules and dev dependences among packages, but let's keep it after moving them all.

The plan is to move packages gradually. For now we have the main part:

• redux-devtools (from current repo)
• redux-devtools-instrument

EDIT: Moved the list of other packages to #412, to keep the track there.

[rufusraghunath]

Hey, as discussed in zalmoxisus/redux-devtools-extension/issues/468, I've had a look at these changes. They look good to me, and the tests are passing.

A few thoughts:

Not sure if moving all the tests in the root part of monorepo instead of having tests inside for every package is better.

I think your current approach with run-in-packages.js is better. Keeping the tests in the individual packages makes it easy to develop the packages and run their tests separately. Just FYI, Jest recursively looks for nested test files out of the box, so if you ever wanted to migrate to Jest, we could remove the Node script :)

Still unsure about publishing and how to proceed with release tags, redux-devtools is at 3.x while it will be just a package and release tags should be mainly about extension, which is 2.x.

For the release tags, I think the only thing we can do is go to the highest version. So either we go to the 3.x version in redux-devtools, or we go straight to 4.0. It's annoying because it breaks semver, but I don't know of any way around this.

For publishing, we should be able to use Lerna's publish flow. That part is usually pretty straightforward. We can use Verdaccio as a local NPM registry to safely test publishing. I found this very helpful last time I worked on a monorepo.

Probably would be great to have the same rules and dev dependences among packages, but let's keep it after moving them all.

Agreed, let's wait to hoist the devDependencies until all the packages are moved.

We can improve this later, I'll just move repos gradually. If you'll have time PRs on improving that would be much appreciated.

OK, I can add try moving some more packages when I have time and make a PR to this branch.

[zalmoxisus]

@rufusraghunath thanks for helping with it!

Just FYI, Jest recursively looks for nested test files out of the box, so if you ever wanted to migrate to Jest, we could remove the Node script :)

I guess that will work only if we have all dependences in the root package and not different versions, otherwise we need to run it from inside the package.

UPDATE: I see there's also lerna run test, and it has a nice option --since to test only what was changed (otherwise we have pretty long e2e tests to wait for). Probably jest can do that too, but for now that would be the best option.

For the release tags, I think the only thing we can do is go to the highest version. So either we go to the 3.x version in redux-devtools, or we go straight to 4.0. It's annoying because it breaks semver, but I don't know of any way around this.

I think we could go for 3.x as a canary/nightly version (since we cannot publish alpha versions on Chrome Store and Mozilla Addons) and 4.x as stable for the extension. But jumping straight from 2.x to 4.x would be pretty confusing. So, I guess the best option is to remove tags from this repository at all and start from 3.x. Those tags referred only for one package, so we might just copy them to ./packages/redux-devtools/CHANGELOG.md.

For publishing, we should be able to use Lerna's publish flow. That part is usually pretty straightforward. We can use Verdaccio as a local NPM registry to safely test publishing. I found this very helpful last time I worked on a monorepo.

Thanks for the hint. Definitely that would be useful at least for testing first release.

OK, I can add try moving some more packages when I have time and make a PR to this branch.

I'm still thinking on an option to move all the contribution history here. The problem is that packages commits conflict with the current repository, and after solving conflicts we're losing the contribution. Might try to make a script to override the history so it will look like everything was in packages/package-name directory from start.

I think it's good to merge this and have separate PR for every package.

In case others want to help too, the most needed help for now would be with upgrading dependences (as most of packages weren't changed for more than 2 years) and adding tests. Also helping with docs is always appreciated. For now we have docs only for redux-devtools, but we need to include information about every package there. The extension and its docs will come at the end.

[rufusraghunath]

I think it's good to merge this and have separate PR for every package.

Won't this block other releases until all the monorepo stuff is done? At least until we have the publishing part sorted?

I guess that will work only if we have all dependences in the root package and not different versions, otherwise we need to run it from inside the package.

I think this works even if you have separate devDependencies. I did this on my last Lerna project... as long as you have a version of Jest installed in the root, it should be able to find all the nested tests and run them.

[zalmoxisus]

@rufusraghunath it'll block other releases if we intend to have the same version for every package on publishing, but I changed version to independent in the commit above (please let me know if you find something wrong or can be added there), so we'll have different versions (for now 1.x for redux-devtools-instrumentation and 3.x for redux-devtools). The releases tag version will be for browser extension only. Similarly how it's on create-react-app releases, the version tag reflects only the main package, while the other packages specified there have different versions.

[zalmoxisus]

Merging this will let us move forward here instead of having changes for current packages outside (like in zalmoxisus/redux-devtools-instrument#24). Some packages like redux-devtools-app, redux-devtools-core and redux-devtools-cli need complete rewrite before merging here. Also there will be new packages, like redux-devtools-trace-monitor, which I'll decouple from zalmoxisus/remotedev-app#43.

The plan is to release version 2.17 of the extension, which will implement showing stack traces, since @markerikson did all the work and it's waiting for 3 months already. That will be the last minor there (except some patches for found bugs), all the next features will be implemented here as 3.x. All issues, except feature requests, were solved in 2.16 during these weeks.

I'll move the list in #412 and we can keep track of what was moved.

[zalmoxisus]

I did this on my last Lerna project... as long as you have a version of Jest installed in the root, it should be able to find all the nested tests and run them.

If you'll have some time later, that would be a great contribution, moving tests to jest. I already moved to jest two years ago (when jest suddenly turned to be the most popular) for remotedev-app, redux-devtools-test-generator and devui, the tests for the rest packages were written earlier when mocha was in vogue 😀

[rufusraghunath]

If you'll have some time later, that would be a great contribution, moving tests to jest.

Sure. It probably makes sense to wait until all the packages are moved, though, because it sounds like a lot of them are still being rewritten.

Apart from that, I'm not sure how helpful I can be. You asked for support with testing, but I don't really have much context on this project, so it would be hard for me to write tests. I'm happy to help with the Jest migration later, though.

[zalmoxisus]

Thanks, also for the feedback here!