-
Notifications
You must be signed in to change notification settings - Fork 4.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Separate visualizations into their own package #4837
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See comments.
Also the folder in the repo, how about we name it viz-lib
?
redash-visualizations/package.json
Outdated
@@ -0,0 +1,77 @@ | |||
{ | |||
"name": "redash-visualizations", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's name it @redash/viz
. I've added you to the redash
org on npm, so you should be able to eventually push it there.
redash-visualizations/package.json
Outdated
@@ -0,0 +1,77 @@ | |||
{ | |||
"name": "redash-visualizations", | |||
"version": "1.0.0", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's start with version 0.1.0 and switch to 1.0 when the API is more stable.
cff5ec4
to
fa0cfbc
Compare
fa0cfbc
to
220ccad
Compare
73307c4
to
ed61df1
Compare
@@ -70,7 +70,7 @@ describe("Visualizations -> Chart -> Editor -> Colors Settings", () => { | |||
.simulate("click"); | |||
}); | |||
|
|||
test("Sets custom color scheme", async done => { | |||
test("Sets custom color scheme", done => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Was this async
important for something I'm missing? It was causing this test to fail removing it didn't cause any harm 🤷♂️
(Probably some babel setting missing for it to work, but it was way easier to just remove it)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think async
is not needed here, so it's ok to remove. Return value is always ignored, and done
is used for async tests
7e5bd3d
to
b0fcfd7
Compare
@@ -2,7 +2,8 @@ FROM node:12 as frontend-builder | |||
|
|||
WORKDIR /frontend | |||
COPY package.json package-lock.json /frontend/ | |||
RUN npm ci | |||
COPY viz-lib /frontend/viz-lib | |||
RUN npm ci --unsafe-perm |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems to be required to run the preinstall script (which installs viz-lib deps and build it) when we run the command as root user. An alternative is to switch the user to the redash one in this scope. I tried to switch to it for all commands, but didn't seem that quick. Another option is to switch to the user only while running this command.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
but didn't seem that quick
in terms of effort required to make the switch?
Regardless, --unsafe-perm
should be safe in the context of running inside a Docker container build...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
in terms of effort required to make the switch?
In terms of changes in that file, mostly needs to update chown/chmod permissions for that folder. As the --unsafe-perm
seemed simpler, I wanted to show it as an option, but needed to confirm regarding safety. I actually didn't sit down and actually tried to change thos yesterday, but I did today and I could get it to work like this:
FROM node:12 as frontend-builder
RUN useradd --create-home redash
WORKDIR /frontend
COPY package.json package-lock.json webpack.config.js /frontend/
COPY viz-lib /frontend/viz-lib
COPY client /frontend/client
RUN chown -R redash /frontend
USER redash
RUN npm ci
RUN npm run build
(notice I changed the COPY
order to run only one chown
, not sure if there was a reason to have it after the npm ci
command though)
Anyway, LMK which option you prefer.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(notice I changed the COPY order to run only one chown, not sure if there was a reason to have it after the npm ci command though)
The reason for the current order is to make sure that we don't have to reinstall if package.json
/package-lock.json
didn't change, as they change less frequently than the codebase.
Let's go with the unsafe option for now.
I'm intrigued by where this is going! 👍 |
Hi @daniellangnet, the idea here is to have visualizations to stand on their own (not to be dependent on any other part of Redash), so they can be turned into a separate package. All the bigger changes for that to be possible were already delivered in past PRs, so this one is mostly a setup + move the visualizations folder. In any case, this is the last one that will have "more significant" changes on the codebase (although it just moves files and it should be an easy merge). The goal is to make it transparent to development flows, so ideally it shouldn't affect your work. Thanks for contributing and I'll give a quick check on your PR anyways. 🙂 |
This PR changes in Brief for ones that will review it:
|
Should we merge this now? |
🚀 |
What type of PR is this? (check all applicable)
Description
Separate visualizations into their own package
To-do list:
p-r-5
from redash-visualizations/src/visualizations/table/utils.jspackage.json
Related Tickets & Documents
--
Mobile & Desktop Screenshots/Recordings (if there are UI changes)
--