Skip to content
This repository has been archived by the owner on Dec 10, 2021. It is now read-only.

refactor: more @superset-ui/core to superset-ui #728

Closed

Conversation

ktmud
Copy link
Contributor

@ktmud ktmud commented Aug 9, 2020

🏠 Internal

Move @superset-ui/core to a new package called superset-ui. This is the first step of merging all @superset-ui/ core packages into one package.

Merges into a feature branch monopackage.

@ktmud ktmud requested a review from a team as a code owner August 9, 2020 05:58
@vercel
Copy link

vercel bot commented Aug 9, 2020

This pull request is being automatically deployed with Vercel (learn more).
To see the status of your deployment, click below or on the icon next to each commit.

🔍 Inspect: https://vercel.com/superset/superset-ui/ok7wmdq4r
✅ Preview: https://superset-ui-git-fork-ktmud-monopackage-move-core.superset.vercel.app

@vercel vercel bot temporarily deployed to Preview August 9, 2020 05:58 Inactive
@@ -1,5 +1,5 @@
import React, { PureComponent } from 'react';
import { isDefined } from '@superset-ui/core';
import { isDefined } from 'superset-ui/lib/core';
Copy link
Contributor Author

@ktmud ktmud Aug 9, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because of restrictions from nimbus, currently we still have to import from the superset-ui/lib folder. I really want to get rid of the /lib folder for published packages, but it would require more advanced customization with the build process that is not easy to do with nimbus.

Will try to revisit this after all packages are merged.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't really understand enough about nimbus to grok these restrictions. Does this also mean we'll have to import from /lib in Superset?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because of restrictions from nimbus

What restriction? I don't remember having that issue before.

Copy link
Contributor

@kristw kristw Aug 10, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I really want to get rid of the /lib folder for published packages

Could you elaborate more on the motivation to remove lib?

Copy link
Contributor Author

@ktmud ktmud Aug 10, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What restriction? I don't remember having that issue before.

nimbus expects the src and outputs to be certain layout and it's difficult to override the defaults.

package.json can specify only one main script, so while you can import lib/index.js directly from "@superset-ui/ui`:

import { abc } from "@superset-ui/abc"

You cannot use import { abc } from "superset-ui/abc" to import from superset-ui/lib/abc/index.js

Copy link
Contributor Author

@ktmud ktmud Aug 10, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't really understand enough about nimbus to grok these restrictions. Does this also mean we'll have to import from /lib in Superset?

For the time-being or before the packages are all merged, yes. We can always merge the feature branch only when we find a solution to get rid of /lib.

It'd be possible to import all of them from the root index file though.

import { SupersetChart } from "superset-ui"

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I really want to get rid of the /lib folder for published packages

Could you elaborate more on the motivation to remove lib?

It just looks better. 😄 Plus it'd also be easier (and less confusing) when we redirect it to the /src folder via resolve aliases, for IDE intellisense or npm link.

But I guess we can live with it if it's too much work or adds too much complexity to the build process.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense. This looks pretty good to me:

import { SupersetChart } from "superset-ui"

Though it may be too many things exported under one namespace.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense. This looks pretty good to me:

import { SupersetChart } from "superset-ui"

Though it may be too many things exported under one namespace.

I think we should export all under one. Seems a lot simpler.
There is also no naming collision at the moment.
(I previously did re-export all subpackages in @superset-ui/superset-ui that re-exports all from the micro packages and there was no name conflicts)

@ktmud ktmud marked this pull request as draft August 10, 2020 01:51
@codecov
Copy link

codecov bot commented Aug 10, 2020

Codecov Report

Merging #728 into monopackage will not change coverage.
The diff coverage is n/a.

Impacted file tree graph

@@             Coverage Diff              @@
##           monopackage     #728   +/-   ##
============================================
  Coverage        24.35%   24.35%           
============================================
  Files              340      340           
  Lines             7637     7637           
  Branches           929      929           
============================================
  Hits              1860     1860           
  Misses            5704     5704           
  Partials            73       73           
Impacted Files Coverage Δ
...s/superset-ui-chart-composition/src/ChartFrame.tsx 100.00% <ø> (ø)
...kages/superset-ui-chart/src/clients/ChartClient.ts 100.00% <ø> (ø)
...ckages/superset-ui-chart/src/models/ChartPlugin.ts 100.00% <ø> (ø)
...ackages/superset-ui-chart/src/models/ChartProps.ts 100.00% <ø> (ø)
...src/registries/ChartBuildQueryRegistrySingleton.ts 100.00% <ø> (ø)
.../src/registries/ChartComponentRegistrySingleton.ts 100.00% <ø> (ø)
...c/registries/ChartControlPanelRegistrySingleton.ts 100.00% <ø> (ø)
...t/src/registries/ChartMetadataRegistrySingleton.ts 100.00% <ø> (ø)
...registries/ChartTransformPropsRegistrySingleton.ts 100.00% <ø> (ø)
...ges/superset-ui-color/src/CategoricalColorScale.ts 100.00% <ø> (ø)
... and 28 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update d323ce8...492cdda. Read the comment docs.

@ktmud ktmud marked this pull request as ready for review August 10, 2020 18:08
@kristw
Copy link
Contributor

kristw commented Aug 10, 2020

Move @superset-ui/core to a new package called superset-ui.

Better use @superset-ui/xxx name to leverage existing npm org for publishing scoped package. Otherwise we will need two permission granting for every new maintainer instead of just giving access to @superset-ui
You can also repurpose @superset-ui/core to be the monopackage.

@ktmud
Copy link
Contributor Author

ktmud commented Aug 10, 2020

Move @superset-ui/core to a new package called superset-ui.

Better use @superset-ui/xxx name to leverage existing npm org for publishing scoped package. Otherwise we will need two permission granting for every new maintainer instead of just giving access to @superset-ui
You can also repurpose @superset-ui/core to be the monopackage.

Sure. I'll use @superset-ui/core.

@ktmud
Copy link
Contributor Author

ktmud commented Aug 10, 2020

We'll just repurpose @superset-ui/core to contain all core packages. Since there is no point to move "@superset-ui/core" to "@superset-ui/core/core", closing this PR and starting to move other packages to core.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants