Hi!

After reading through #1053243, I realized that Alertmanager is not
the only Prom thing that has a "modern" UI buried out of the Debian
package, but that Prometheus itself has a "React" UI available.

And now, checking on the unstable package, I see that the "classic" UI
has actually been completely removed from upstream. So far we're
bundling the classic UI in the package, but that's deemed to be
removed in the future.

Let's not do the alertmanager thing here, and somehow figure out how
to package this properly. I understand it's a gooey Javascript thing,
but we *do* have a bunch of Javascript things in Debian, and I think
it's a solveable problem. At least it doesn't look like it has Elm
compiler stuff?

According to:

https://github.com/prometheus/prometheus/tree/main/web/ui#pre-requisite

We need npm >= v7 (already in bookworm, even!) and nodejs >= 20 (in
trixie). I'm not *super* familiar with the javascript packaging, but
it *looks* like the package.json file is not completely hopeless:

https://github.com/prometheus/prometheus/blob/main/web/ui/package.json

... but of course, it hides the uglier part of it where you have react
and friends:

https://github.com/prometheus/prometheus/blob/main/web/ui/mantine-ui/package.json

... but we *do* have react and friends and debian now! So I think it
might be worth tackling that one and looking at what, exactly, we're
missing from Debian that we could add to make this work and keep
having a working web UI in Prometheus for the forseeable future.

Thanks!

Antoine,

I think you know as well as I do that the likelihood of this being
feasible is pretty remote. The fact that sufficient versions of npm,
nodejs and React are already available in Debian does not help much if
the web app uses a ton of bleeding edge modules which are not even on
anybody's radar to package for Debian. Combine that with the fact that
the Prometheus web UI is getting yet another major overhaul for v3.0.0.
It seems to be a fast-moving target.

The classic web UI was actually removed upstream in v2.34.0, and I have
forward-ported / reinstated the necessary Go code to keep supporting it.
This is a dead end however, since Prometheus has newer functionality
like exemplars and native (sparse) histograms, which are not supported
by the legacy web UI. I would prefer to see the Debian package finally
drop the classic UI also, since the Debian package is starting to
resemble more of a /fork/ of Prometheus.

You may have noticed that I recently added an install-ui.sh helper
script to the prometheus package, to fetch the React web UI tarball from
upstream, similar to the script that is bundled with
prometheus-alertmanager. So you /can/ use the React web UI now, if you want.

If you're willing to pitch in and help package the React UI, by all
means, please do.

I know, but i think it's worth, if not trying, at least keeping track of
how and why it's not possible. :)

Yeah, I'm kind of hoping they stop doing that already with the v3. But i
will note that people *are* trying to keep up with a lot of modules like
this for other projects, and I think it's actually possible to give it a
try already.

I would also argue *for* vendoring the stuff that's not practical to
package. We have a few special precedents in Debian for important
packages that have bent the rules a little bit to ship vendored copies
of source code (firefox and kubernetes, for example), and I think we
could get away with shipping a couple javascript libraries like this.

Yep, this is mainly why I've opened that issue, actually.

Yes, I've seen that! I have even tried it out, but it didn't work out so
well for me, something which could perhaps be filed as a separate bug.
I *might* get time to deal with this in the coming *year* (aka "2025",
definitely not until January), so I wanted to see if there was at least
*some* openness in dealing with it.

Also, we're not alone with this: there's a bunch of people working on
JavaScript stuff in Debian, and we could get some help there.

So the question is: do we, as a golang team (and you, as an uploader for
this package), want to do this? Or do we want to fundamentally object to
even trying to fix this issue?

Because this is essentially why i filed this issue: I don't expect
anyone to just drop everything and do this. I want to see if people are
okay with us trying to do this.

Thanks for considering my request, in any case! :)

A.

The v3.0.0 uses a totally different (and presumably quite new) framework
called Mantine (https://mantine.dev/), so it's anybody's guess when that
will be usable within Debian. I don't see any relevant ITP or RFP bugs
for it. Given that the prometheus package is struggling to advance
beyond a "LTS-1" version due to missing Go build-deps, it could be a
while before we can even contemplate packaging v3.

If the Prometheus package gets a pass in that respect, it would surely
make things a lot simpler, as we could stop de-blobbing the embedded
assets, and basically not have to give any thought whatsoever to
building the UI from scratch. I'm not sure how likely this is though.

It only works with the sid / trixie package (>= 2.45.6+ds-2), since
previous versions also had the backend Go code used by the React UI
stripped out. You also need to explicitly request the "/graph" URL,
since landing on the root "/" URL will redirect you to "/classic/graph".
I will reinstate a link to the "new" UI in the classic UI, which
upstream versions included whilst the two variants were still officially
supported. Unless you have run the "install-ui.sh" script however,
landing on the new UI URL will display an index.html explaining the
situation (à la prometheus-alertmanager).

Yes, and it would be enormously appreciated if they could at least get
the ball rolling in terms of what is needed to start building the React
UI with the package. I have never done any JavaScript packaging in
Debian, but if somebody suitably qualified lays the groundwork, I can
probably maintain it in the long run.

I have no objection to this, and it would be awesome if people can come
together to make it happen. I don't have the time (or expertise) to do
this single-handedly. It's been /years/ since I did any frontend
development, back in the heyday of jQuery. I never got into npm /
nodejs, and have not worked with React (or Typescript in general). So I
would be totally outside of my comfort zone if I attempted this.

I will at least paste this list of dependencies [1], with what I _think_
are the Debian packages alongside in square brackets.

   "dependencies": {
     "@codemirror/autocomplete": "^6.17.0",  [node-codemirror-autocomplete]
     "@codemirror/commands": "^6.6.0",  [node-codemirror-commands]
     "@codemirror/language": "^6.10.2",  [node-codemirror-language]
     "@codemirror/lint": "^6.8.1",  [node-codemirror-lint]
     "@codemirror/search": "^6.5.6",  [node-codemirror-search]
     "@codemirror/state": "^6.3.3",  [node-codemirror-state]
     "@codemirror/view": "^6.29.1",  [node-codemirror-view]
     "@forevolve/bootstrap-dark": "^4.0.2",  [???]
     "@fortawesome/fontawesome-svg-core": "6.5.2",
[node-fortawesome-fontawesome-svg-core]
     "@fortawesome/free-solid-svg-icons": "6.5.2",
[node-fortawesome-free-solid-svg-icons]
     "@fortawesome/react-fontawesome": "0.2.0",  [???]
     "@lezer/common": "^1.2.1",  [node-lezer-common]
     "@lezer/highlight": "^1.2.0",  [???]
     "@lezer/lr": "^1.4.2",   [???]
     "@nexucis/fuzzy": "^0.4.1",  [???]
     "@nexucis/kvsearch": "^0.8.1",  [???]
     "@prometheus-io/codemirror-promql": "0.55.0-rc.0",  [???]
     "bootstrap": "^4.6.2",  [libjs-bootstrap4]
     "css.escape": "^1.5.1",  [???]
     "downshift": "^9.0.6",  [???]
     "http-proxy-middleware": "^3.0.0",  [???]
     "jquery": "^3.7.1",  [libjs-jquery]
     "jquery.flot.tooltip": "^0.9.0",  [???]
     "moment": "^2.30.1",  [libjs-moment]
     "moment-timezone": "^0.5.45",  [libjs-moment-timezone]
     "popper.js": "^1.14.3",  [libjs-popper.js]
     "react": "^17.0.2",  [node-react]
     "react-copy-to-clipboard": "^5.1.0",  [???]
     "react-dom": "^17.0.2",  [node-react-dom]
     "react-infinite-scroll-component": "^6.1.0",  [???]
     "react-resize-detector": "^7.1.2",  [???]
     "react-router-dom": "^5.3.4",  [???]
     "react-test-renderer": "^17.0.2",  [node-react-test-renderer]
     "reactstrap": "^8.10.1",  [???]
     "sanitize-html": "^2.13.0",  [node-sanitize-html]
     "sass": "1.77.6",  [node-node-sass]
     "tempusdominus-bootstrap-4": "^5.39.2",  [???]
     "tempusdominus-core": "^5.19.3"  [???]
   },

It definitely looks better than it did a couple of years ago when I
looked into this, but there are still a fair number of "[???]"
occurrences, where I was not able to find any packages that resemble
what is being referred to.

[1]:
https://github.com/prometheus/prometheus/blob/main/web/ui/react-app/package.json

[...]
one stripped down, without the react core (which would be useful
anyways!) and one with the blobs, that could perhaps be shipped in
contrib...

[...]

yes! i looked too, and this is also why i felt confident filing this bug
:)

Yep, those are the sticky bits. :)

Hi!

I'm part of the golang team (in CC) which is responsible for packaging
the Prometheus package, a golang-based monitoring system. Recently,
upstream switched from a "classic" HTML-based interface to a rather
more... complicated JavaScript frontend built with React.

We've looked at packaging this in Debian (#1083100, also in CC), and
quickly got worried about the number of dependencies we'd need to
package.

Do you have advice on how to move forward on this?

I was wondering if there's some magic command we can run to actually get
a more solid view on the tasks needed? Like a command that would parse
the package.json and report which packages are missing from Debian,
which have WNPP bugs, etc...

How involved is it to package React stuff?

How maintainable is it in the long run in Debian?

Thanks for any advice!

a.

Hi,

There is npm2deb. Running `npm2deb depends -b -r <pkg name in npm dot js>` can give you an idea about the dependency tree (the commands might be a bit different, it's been a while since I last dealt with it). Although I have to warn you that it is...... *very slow*.

Best,
Ananthu

Le lun. 7 oct. 2024 à 18:27, Antoine Beaupré <anarcat@debian.org> a écrit :

Can you give the link to the upstream package.json file that pulls the
dependencies, thanks.

Of course! I believe it is:

https://github.com/prometheus/prometheus/blob/main/web/ui/mantine-ui/package.json

... which is called from:

https://github.com/prometheus/prometheus/blob/main/web/ui/package.json

i *think* the "react-app/" directory is the older implementation, which
can be disregarded.

Thanks!

Le lun. 7 oct. 2024 à 19:18, Antoine Beaupré <anarcat@debian.org> a écrit :

Thanks,

I think the proper method will be to mut-bundle as much, and as cleanly, as
possible,
with most packages not re-exported to /usr/share/nodejs, because it is just
asking for trouble.

There are tools to help in that task, like pkgjs-tools' add-node-component.
It requires some skills. I can help, but I don't have time to do it
entirely.
It's going to be difficult to get this into trixie, unless someone works
really hard on it right now.

Hi all,

A bit late to the party, but I have just uploaded prometheus 2.53.1 to
unstable, after a long wait due to the constant problem of outdated or
missing dependencies.

This is the last LTS (lont-term support) release of the 2.x series, so I
really wanted to have this in trixie. As things stand, we won't be able
to upgrade to 3.x in time, plus there is no 3.x LTS release yet; so I
think this is a good version to include in trixie.

Considering all this, it might be worth seeing if it is possible at all
to try to build the "old" react UI from source, resorting to vendoring
in NPM dependencies, as it looks that the lit might not be that long at
this point. In the last couple of years, I have gained quite a bit of
experience with JavaScript and NodeJS (on the backend side mostly), but
I still struggle with the Debian packaging tools. So maybe with a bit of
help with somebody from the JS team we can try this?

This would actually be the one we can try to build, which corresponds to
the list of dependencies Daniel listed in October.

Jérémy, could you explain what do you mean by "mut-bundle"? I can't find
any package name resembling that..

Agreed.

Would this be using multiple source tarballs? I wonder if that wouldn't
conflict with the usual workflow where we don't rely on pristine-tar but
on upstream git history. I guess an option could be to package this in a
separate source package, but I'd like to avoid any extra steps and trips
to NEW.

Tina.

Le lun. 10 févr. 2025 à 06:43, Martina Ferrari <tina@tina.pm> a écrit :
https://sources.debian.org/src/node-webfont/11.4.0+dfsg2+~cs35.7.26-10/debian/watch/?hl=12#L12

I'm sure what's the best package to serve as an example of dh-nodejs usage,
however it's good to skim through sources.debian.org, and read
https://wiki.debian.org/Javascript/GroupSourcesTutorial


I never found a way to make both (m.u.t. and upstream git history) work.
Maybe it's possible, though.

I guess an option could be to package this in a

The simplest solution, by far, is to switch to the other gbp layout
(without git history).

Jérémy