this is from december :-)
https://www.wiz.io/blog/critical-vulnerability-in-react-cve-2025-55182

Patrick

On Tue, Mar 31, 2026 at 7:27 AM Yurii Palamarchuk <
[email protected]> wrote:

> You are right, there are almost no concerns. The entire website is static,
> only the server providing the assets is running. The only issue could be if
> some node.js package becomes vulnerable, allowing hackers to run scripts on
> users' machines, but this scenario is highly unlikely.
>
> Best Regards,
> Yurii
>
> On Tue, Mar 31, 2026 at 4:22 PM Patrick Hunt <[email protected]> wrote:
>
> > What are the security implications of running React on the ZK website? Is
> > that going to mean additional concerns (eg cve tracking as well as source
> > security bugs, tracking the "latest react" version and so on...). I
> > believe right now we just have very simple static pages which require
> very
> > minimal oversight?
> >
> > Regards,
> >
> > Patrick
> >
> > On Tue, Mar 31, 2026 at 7:17 AM Yurii Palamarchuk <
> > [email protected]> wrote:
> >
> > > Thanks everyone for your reviews!
> > >
> > > The only approach I considered for updating the documentation version
> is
> > a
> > > manual one. It looks like this:
> > > 1) Checkout to the `website` branch.
> > > 2) Build the latest change for the current version, right before the
> > > update.
> > > 3) Move the build to `public/released-docs/` and rename the directory
> to
> > > the corresponding version.
> > > 4) Update the `CURRENT_VERSION` constant, so now it matches the new
> > > version.
> > > 5) Open a PR.
> > >
> > > The Java API docs are built by maven as far as I can tell, so it's not
> > > related to the website actually.
> > >
> > > Regarding the automatization of this process, I've never done anything
> > like
> > > this before. Therefore, if you have any suggestions - I'm open to it, I
> > > think it should be possible since the workflow is not complex at all.
> > Most
> > > likely a small bash script could be enough.
> > >
> > > Best Regards,
> > > Yurii
> > >
> > > On Tue, Mar 31, 2026 at 3:09 AM Andor Molnár <[email protected]> wrote:
> > >
> > > > Exactly. My 2 cents are:
> > > >
> > > > 1. Storing the entire website at a single location is desirable.
> Given
> > > the
> > > > proposed
> > > > technology changes there’s no clear separation possible without
> > > duplicating
> > > > website core logic components which will be a maintenance nightmare
> in
> > > the
> > > > long term.
> > > >
> > > > 2. Separate ‘website’ branch or versioned branches. As Patrick
> > mentioned
> > > > the docs are versioned and the ability to accompany doc changes with
> > > > code changes in the same PR is a big advantage.
> > > >
> > > > Andor
> > > >
> > > >
> > > >
> > > >
> > > > > On Mar 30, 2026, at 19:52, Patrick Hunt <[email protected]> wrote:
> > > > >
> > > > > One reason I remember the docs/api/etc... are part of the source is
> > > that
> > > > > they are versioned along with it. PRs -- doc changes along with
> code
> > > > > changes also part of the release process.
> > > > >
> > > > > Patrick
> > > > >
> > > > > On Mon, Mar 30, 2026 at 5:39 PM Christopher <[email protected]>
> > > wrote:
> > > > >
> > > > >> I think it looks great, but I would really like to see the SCM
> > source
> > > > >> for this new site, so I can understand the maintenance/build
> > workflow
> > > > >> for it, before I'd have any useful opinion other than regarding
> > > > >> aesthetics.
> > > > >>
> > > > >> I definitely concur with moving the docs out to the site to
> > centralize
> > > > it.
> > > > >>
> > > > >> On Fri, Mar 27, 2026 at 3:03 PM Yurii Palamarchuk
> > > > >> <[email protected]> wrote:
> > > > >>>
> > > > >>> Thanks for your comment, Patrick.
> > > > >>>
> > > > >>> Why React?
> > > > >>> Building a website nowadays is not just HTML + CSS, because doing
> > it
> > > > this
> > > > >>> way turns the developer experience into a nightmare. With React
> we
> > > > >>> effortlessly have consistent UI components across all pages,
> > > including
> > > > >>> buttons, tables, markdown rendering, colors, and much more. We
> also
> > > add
> > > > >> the
> > > > >>> interactivity much more easily with React. A static website
> doesn't
> > > > mean
> > > > >> it
> > > > >>> lacks interactivity; it often has significant interactivity,
> > > especially
> > > > >> in
> > > > >>> the documentation section. The difference is that we don't need
> any
> > > > >> runtime
> > > > >>> environment, we just return the files generated at build time,
> > which
> > > > are
> > > > >>> ultimately just HTML, CSS, and JS. The website also has dark mode
> > > > >> support,
> > > > >>> search in the documentation, smooth transitions between pages (no
> > > hard
> > > > >>> reload), so it gives smooth and better user experience overall. I
> > > hope
> > > > >> this
> > > > >>> answers your question. Moreover, the website will work absolutely
> > > fine
> > > > >> even
> > > > >>> for those who have JS disabled, this is called progressive
> > > enhancement.
> > > > >>> Initially, the server returns HTML and CSS. The browser renders
> > them
> > > > and
> > > > >>> tries to fetch the JS files. If it doesn't succeed, the page
> > remains
> > > > >>> accessible, though it obviously lacks interactivity. I hope this
> > > > answers
> > > > >>> your questions, if not, feel free to ask more about it!
> > > > >>>
> > > > >>> Is it hard for ZK devs to update the content?
> > > > >>> Not at all! I tried to make it so the learning curve for non-JS
> > devs
> > > is
> > > > >>> almost 0. For the documentation you still just need to edit the
> MDX
> > > > >>> (Markdown Extended) files and run the build command. I will also
> > add
> > > a
> > > > >> bash
> > > > >>> script to automate the build process. For the landing pages, you
> > > still
> > > > >>> mostly only need to modify the markdown files. Only the main page
> > > isn't
> > > > >>> markdown, modifying something small wouldn't be a problem. In the
> > > worst
> > > > >>> case, if something more complex is required, you can handle it
> with
> > > the
> > > > >> AI.
> > > > >>> Nevertheless, the website hasn't been updated for years, so it
> > > wouldn't
> > > > >> be
> > > > >>> a big loss :)
> > > > >>>
> > > > >>> Best regards,
> > > > >>> Yurii
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>> On Fri, Mar 27, 2026 at 4:19 PM Patrick Hunt <[email protected]>
> > > wrote:
> > > > >>>
> > > > >>>> On Fri, Mar 27, 2026 at 3:32 AM Yurii Palamarchuk <
> > > > >>>> [email protected]> wrote:
> > > > >>>>
> > > > >>>>> Hi there,
> > > > >>>>>
> > > > >>>>> I am proposing an upgrade to the ZooKeeper website and
> > > > >> documentation. We
> > > > >>>>> are moving to a modern React.js stack, which allows landing
> pages
> > > and
> > > > >>>>> versioned documentation to live in a single application sharing
> > the
> > > > >> same
> > > > >>>> UI
> > > > >>>>> components, libraries, colors, etc.
> > > > >>>>>
> > > > >>>>> The plan is to move all website and documentation source code
> to
> > > the
> > > > >>>>> website branch and remove the zookeeper-docs Maven project from
> > the
> > > > >>>> master
> > > > >>>>> branch. This decouples the Node/JS build environment from the
> > core
> > > > >> Java
> > > > >>>>> repository.
> > > > >>>>>
> > > > >>>>> Versioned docs will be managed via archived folders within the
> > > > >> website
> > > > >>>>> branch. Documentation updates would move from master to PRs
> > against
> > > > >> the
> > > > >>>>> website branch. Also I'm not planning to keep the app as a
> maven
> > > > >> project,
> > > > >>>>> since it's fully JS based. To keep it simple, I will write a
> bash
> > > > >> script
> > > > >>>>> that installs the dependencies, runs the tests, and the build.
> > > > >>>>>
> > > > >>>>> What do you think about moving the docs out of master to
> > centralize
> > > > >> the
> > > > >>>>> site?
> > > > >>>>>
> > > > >>>>> Preview: https://zookeeper-website.vercel.app/
> > > > >>>>>
> > > > >>>>>
> > > > >>>> Looks pretty slick - nice update and visual refresh! Question
> > > though -
> > > > >> why
> > > > >>>> React? This is a static website, what are the pro/con of React
> > > based?
> > > > >> Can
> > > > >>>> you explain the impact on common use cases like making updates?
> ZK
> > > > team
> > > > >>>> includes a number of people, not all of whom might know React,
> how
> > > > hard
> > > > >>>> will it be for them to make changes? Impact on the release
> > process?
> > > > >>>>
> > > > >>>> Regards,
> > > > >>>>
> > > > >>>> Patrick
> > > > >>>>
> > > > >>>>
> > > > >>>>> Best regards,
> > > > >>>>> Yurii Palamarchuk
> > > > >>>>>
> > > > >>>>
> > > > >>
> > > >
> > > >
> > >
> >
>

Reply via email to