Here is the code: https://github.com/yuriipalam/zookeeper-website
It's not a PR for the zookeeper repo yet. Regards, Yurii On Thu, Apr 2, 2026 at 3:33 AM Christopher <[email protected]> wrote: > Where is the code for the react version of the site? > > On Wed, Apr 1, 2026 at 2:53 AM Dávid Paksy <[email protected]> wrote: > > > > Hi All, > > > > To have a sense about maintenance need, you can see the JavaScript > > dependabot PR-s in the HBase repo here: > > > > > https://github.com/apache/hbase/pulls?q=is%3Apr+author%3Aapp%2Fdependabot+is%3Aclosed+label%3Ajavascript > > > > So yes, it requires some maintenance. > > I'd also recommend to enable Dependabot dependency updates as they are > > helpful. But if not, running 'npm audit fix' manually is rather easy. > > > > For how the sources look you can check here what Yuri implemented for > HBase: > > > > https://github.com/apache/hbase/tree/master/hbase-website > > > > > > Best regards, > > Dávid > > > > Christopher <[email protected]> ezt írta (időpont: 2026. márc. 31., Ke > > 22:47): > > > > > It's also pretty easy to use dependabot on the website repo to check > > > for updated site dependencies. That should be easy to handle if the > > > assets are included in the repo itself, and not loaded from other > > > domains, as per the ASF policy > > > (https://privacy.apache.org/policies/website-policy.html) > > > > > > On Tue, Mar 31, 2026 at 11:05 AM Yurii Palamarchuk > > > <[email protected]> wrote: > > > > > > > > I know about it, and we're not affected by it. This vulnerability > allows > > > > attackers to bypass the React's server authentication, but we don't > use > > > it. > > > > We don't have any runtime node.js server, so we aren't affected by > any of > > > > these. > > > > > > > > Best Regards, > > > > Yurii > > > > > > > > On Tue, Mar 31, 2026 at 4:38 PM Patrick Hunt <[email protected]> > wrote: > > > > > > > > > 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 > > > > > > > > > >>>>> > > > > > > > > > >>>> > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
