Conversation
* [ENHANCEMENT] theme: add support for color-scheme Signed-off-by: Guillaume LADORME <Gladorme@users.noreply.github.com> * Add prop for enabling/disabling Signed-off-by: Guillaume LADORME <Gladorme@users.noreply.github.com> --------- Signed-off-by: Guillaume LADORME <Gladorme@users.noreply.github.com>
#89) Bumps the gomod group with 1 update: [github.com/perses/perses](https://github.com/perses/perses). Updates `github.com/perses/perses` from 0.53.0 to 0.53.1 - [Release notes](https://github.com/perses/perses/releases) - [Changelog](https://github.com/perses/perses/blob/main/CHANGELOG.md) - [Commits](perses/perses@v0.53.0...v0.53.1) --- updated-dependencies: - dependency-name: github.com/perses/perses dependency-version: 0.53.1 dependency-type: direct:production update-type: version-update:semver-patch dependency-group: gomod ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
beee1a0 to
36652f4
Compare
Signed-off-by: Augustin Husson <augustin.husson@amadeus.com>
|
mmm probably I made a mess with the schema type in the spec repo, but then I don't know how to fix it exactly. Should I change something here, or should I change something in the spec, that's the question |
Signed-off-by: Augustin Husson <augustin.husson@amadeus.com>
Signed-off-by: Augustin Husson <augustin.husson@amadeus.com>
There was a problem hiding this comment.
Issue with your unit test pipeline
There is a subtle issue in your resolver.
I guess the following line is troublesome and you need to update it.
According to this rule, jest tries to find a sibling dir in the root called spec.
spec/src
Line 32 in f8cd4b7
Signed-off-by: Augustin Husson <augustin.husson@amadeus.com>
| import { legendModes, legendSizes } from '@perses-dev/core'; // TODO | ||
| import * as table from '../../Table'; |
There was a problem hiding this comment.
Question,
You have put a comment TODO.
- Does TODO mean that these will be later exposed from Spec and should be imported from there?
- If the first question is valid, then, Do we have any plans to move legend.ts to the Spec and expose it from there? If yes, is there any reason that we have not done it yet?
- Again if the first question is valid, shouldn't we first move everything (those which make sense to be in Spec) to the Spec, and then clean the shared?
There was a problem hiding this comment.
so everything that was required to move to spec has been moved. So, excepting if I missed something, there won't anything else to put in the spec repo.
The todo is there to decide what we should do about this import. Do we need to change the code to avoid this import ? Do we need to move the code imported in another package in the shared repository.
For each import, these questions are relevant. I have already assessed for some import what to do.
These efforts and questions are part of the cleaning work to be done to have a clear API for the embedding feature.
| import { render, screen } from '@testing-library/react'; | ||
| import userEvent from '@testing-library/user-event'; | ||
| import { FormatOptions } from '@perses-dev/core'; | ||
| import { FormatOptions } from '@perses-dev/core'; // TODO |
There was a problem hiding this comment.
| import { Button, Divider, Stack, StackProps } from '@mui/material'; | ||
| import { ReactElement } from 'react'; | ||
| import { Action } from '@perses-dev/core'; | ||
| import { Action } from '@perses-dev/core'; // TODO the internal permission system of Perses should not be in a shared library |
There was a problem hiding this comment.
Question,
Since I am working on the Core at the same time,
As long as members of roles.ts are exposed from Core, they might be misused by dependent packages.
If internal stuff of Perses must stay in the Perses, shouldn't we move roles.ts members to ui/app?
And if we do that, then it will be a breaking change. Are we OK with that?
No description provided.