[WIP] Frontend monorepo

[ktmud]

CATEGORY

• Build / Development Environment

SUMMARY

@kristw @rusackas This is what I meant in #9187. Frontend packages will be organized as such:

├── lerna.json
├── package-lock.json
├── package.json
├── packages
│   ├── superset-app   
│   ├── superset-ui-demo
│   └── superset-ui-plugins-demo
├── superset-ui
│   ├── chart
│   ├── chart-composition
│   ├── color
│   ├── ...
└── superset-ui-plugins
    ├── egacy-rose
    ├── icicle-event
    ├── legacy-calendar
    ├── legacy-chord
    ├── ...

There's enough isolation for optional plugins, but development imports and plugin update workflows can be made very easy... There's obviously more work needed to actually make this work, but I think it's a direction worth pursuing. What do you think?

[rusackas]

On the one hand, it might make life easier, as I don't love the double-PR flow needed to make changes right now, and this resolves at least that issue. On the other hand, there are two potential issues that jump to the top of my mind: 1) this is a step away from having an ecosystem of plugins from 3rd party repos, and 2) I think that one of the reasons these were moved to their own repo in the first place had to do with isolating the licenses of certain packages from the core Apache release. I worry that this'll be another difficult thing to unwind later, but concede that it may make life easier for today. I'm curious what @kristw and @mistercrunch think of the idea.

[kristw]

@rusackas

1. this is a step away from having an ecosystem of plugins from 3rd party repos

Right. A 3rd party repo will run into the same problem and we need to build dev tools to support anyway. Better dogfood that.

2. I think that one of the reasons these were moved to their own repo in the first place had to do with isolating the licenses of certain packages from the core Apache release. I worry that this'll be another difficult thing to unwind later, but concede that it may make life easier for today.

+1

Another reason of moving out is we are using most (if not all) of the quota for running multiple ci jobs in parallel per repo. We spent lots of effort in cutting down ci time at one point to improve the developer experience in this repo. If we bring all these packages into it, it will bring a few more ci jobs along.

[rusackas]

@ktmud Now that your (amazing) npm link work is in, I guess we can close this one? Up to you :D

[ktmud]

I'm still not liking the double PR workflow and the manual process of going back and forth editing package versions while maintaining two open PRs. But I guess that's a small price to pay to get the benefits that motivated the split in the first place.

[rusackas]

I'm still not liking the double PR workflow and the manual process of going back and forth editing package versions while maintaining two open PRs. But I guess that's a small price to pay to get the benefits that motivated the split in the first place.

Agreed... hopefully we can get ALL of the plugins' parts into their own repo, and remove/reduce double-PR pains.