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 > > > > > > > >>>>> > > > > > > > >>>> > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
