feat: Update Node toolchain to version 24 for crud-web-apps

[yehudit1987]

feat: Update Node toolchain to version 24 for kubeflow-common-lib ( #728 )

• Update common_frontend_tests.yaml workflow to use Node 24
• Add engines field to kubeflow-common-lib package.json to enforce Node >=24 <25 and npm >=10
• Update all web app Dockerfiles (JWA, VWA, TWA) to use node:24-bookworm for building the common library
• Update common README.md documentation to reflect Node 24 usage

The Dockerfiles needed updating because they build the kubeflow-common-lib,
and npm respects the engines field during 'npm ci', requiring Node 24.

feat: Upgrade Node.js to 24 for Jupyter Web App frontend (#729 )

• Update jwa_frontend_tests.yaml workflow to use Node 24 in all three jobs (format/lint, unit tests, UI tests)
• Add engines field to JWA frontend package.json to enforce Node >=24 <25 and npm >=10

feat: Upgrade Node.js to 24 for Tensorboards Web App frontend (#730 )

• Update twa_frontend_tests.yaml workflow to use Node 24 in all three jobs (format/lint, unit tests, UI tests)
• Add engines field to TWA frontend package.json to enforce Node >=24 <25 and npm >=10
• Update tensorboards README.md documentation to reflect Node 24 requirement

feat: Upgrade Node.js to 24 for Volumes Web App frontend (#731 )

• Update vwa_frontend_tests.yaml workflow to use Node 24 in all four jobs (format/lint, unit tests, chrome UI tests, firefox UI tests)
• Add engines field to VWA frontend package.json to enforce Node >=24 <25 and npm >=10
• Update Volumes README.md documentation to reflect Node 24 requirement

Validation

Local Build:

• Built successfully with Node 24.11.1 and npm 11.6.2
• All frontend tests passing

Integration Testing:

• Deployed kind cluster with Kubeflow using deployment scripts from https://github.com/andyatmiami/kubeflow-scripts/tree/main
• Deployed web apps with Node 24 changes from this repository
• All web app services started successfully
• UI accessible and functional
• Successfully created and managed resources (notebooks, tensorboards, volumes) via web UI
• No runtime errors or compatibility issues observed

[google-oss-prow]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign thesuperzapper for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[liavweiss]

Thank you, Yehudit
/lgtm

[andyatmiami]

Thanks @yehudit1987 - great start here! Wanna get these first round of review changes incorporated to kinda "lock things in" - and then I will focus on testing/live-reviewing a running cluster with these changes.

One other area I'm truly not sure on - but commenting here for transparency - is what to do about the @types/node dependency in related package.json files 🤔

• "@types/node": "^12.11.1", is what all web-apps declare in devDependencies currently
• this was already incorrect as ideally we should have been using ``"@types/node": "^16.y.z"forbullseye` NodeJS release 😢
• further unclear then what we wanna do in this PR?
  • update to ^24.y.z
  • update it to ^20.y.z
    • still wrong - but at least a little more current
  • leave it alone
    • YOLO

[andyatmiami]

Did you perform any analysis to understand the (significant) changes being introduced in this file? Note that I have not (yet) done analysis myself - but just seeing the raw numbers at this scale is slightly concerning 😇

• 3,449 additions
• 13,996 deletions

Deletions are a good thing (normally) - I just wanna ensure we understand and are comfortable with these edits.

[yehudit1987]

I must admit it's not my expertise here so I will share what I actually did:
1. Ran npm install with Node 24 to regenerate the lockfile
2. Verified the build still works: npm run build
3. Deployed to kind cluster and tested - everything works
4. Checked that package.json has ZERO dependency changes (only added engines field)
5. Confirmed package count is nearly identical (~1,350 packages before/after)
Now I do understand that npm 11 (Node 24) uses a different lockfile format and that massive deletions are mainly format changes. But I'm really not sure what can be counted as a proper analysis beyond that but will be happy to get some recommendations.

[andyatmiami]

Can you comment on why these import statements needed to change? Not against the change - only that I don't see any reference in the commit message about why this was required... and naively I wouldn't understand why a NodeJS upgrade would require these edits to test files

• particularly since it appears ONLY the jupyter web app required this type of adjustment

Furthermore - I'm confused on the stylistic pattern being introduced here:

import { test, expect } from '@playwright/test';
import type { Page } from '@playwright/test';

• here we split the Page (type) import into its own line

import { setupCustomPage, type CustomPage } from '../support/e2e';

• here we keep the single import but prefix CustomPage with type

I would prefer to keep the single-line variant if possible 😇

[yehudit1987]

Great catch on the inconsistency! Let me clarify:

In the most simple words - tests were failing. Reasons:

1. JSON import syntax: Node 24 requires with { type: 'json' } instead of assert { type: 'json' } (ES2025 spec change). This was a breaking change.
2. Why only Jupyter: Only Jupyter uses Playwright for E2E tests. Volumes and Tensorboards use Cypress, which doesn't have these import patterns.

I'll update the test files to use consistent inline type prefixes throughout.

[andyatmiami]

see comment on components/crud-web-apps/jupyter/frontend/tests/e2e/form-page.spec.ts

[andyatmiami]

see comment on components/crud-web-apps/jupyter/frontend/tests/e2e/form-page.spec.ts

.. and also - we now see a 3rd variable on import declarations... whereby type is specified outside the {...} block..
- I assume this would have the effect of enforcing the type qualifier on ALL referenced items in the {...} - which makes sense if my interpretation is correct

[yehudit1987]

Yes that's correct.

[andyatmiami]

see comment on components/crud-web-apps/jupyter/frontend/tests/e2e/form-page.spec.ts

In the name of consistency - i'm wondering if this should be:

• import type { Page } from '@playwright/test';
  OR
• import { type Page } from '@playwright/test';

WDYT?

[yehudit1987]

Not sure but my guess would be, have the type inside the brackets only if you have mixed types. So for this case even if it's just one import outside seems better to me.

[andyatmiami]

for more deterministic builds - I think we should fix this new version to a major/minor/patch version just like it was originally.

Suggested change

	FROM node:24-bookworm as frontend
	FROM node:24.11.1-bookworm as frontend-kubeflow-lib

[andyatmiami]

for more deterministic builds - I think we should fix this new version to a major/minor/patch version just like it was originally.

Suggested change

	FROM node:24-bookworm as frontend-kubeflow-lib
	FROM node:24.11.1-bookworm as frontend-kubeflow-lib

[yehudit1987]

Good catch! I've pinned all Node base images to 24.11.1-bookworm.

[andyatmiami]

for more deterministic builds - I think we should fix this new version to a major/minor/patch version just like it was originally.

Suggested change

	FROM node:24-bookworm as frontend
	FROM node:24.11.1-bookworm as frontend-kubeflow-lib

[andyatmiami]

for more deterministic builds - I think we should fix this new version to a major/minor/patch version just like it was originally.

Suggested change

	FROM node:24-bookworm as frontend-kubeflow-lib
	FROM node:24.11.1-bookworm as frontend-kubeflow-lib

[andyatmiami]

for more deterministic builds - I think we should fix this new version to a major/minor/patch version just like it was originally.

Suggested change

	FROM node:24-bookworm as frontend
	FROM node:24.11.1-bookworm as frontend-kubeflow-lib

[yehudit1987]

Thanks @yehudit1987 - great start here! Wanna get these first round of review changes incorporated to kinda "lock things in" - and then I will focus on testing/live-reviewing a running cluster with these changes.

One other area I'm truly not sure on - but commenting here for transparency - is what to do about the @types/node dependency in related package.json files 🤔

• "@types/node": "^12.11.1", is what all web-apps declare in devDependencies currently

• this was already incorrect as ideally we should have been using ``"@types/node": "^16.y.z"forbullseye` NodeJS release 😢

• further unclear then what we wanna do in this PR?

  • update to ^24.y.z

  • update it to ^20.y.z

    • still wrong - but at least a little more current

  • leave it alone

    • YOLO

Ok did some research and found this -

• Upgrade of type/node should take in account also version of typescript - in our case 4.7.0-4.8.0
• type/node of version 24.y.z is not supporting our versions of typescript.
• In that case upgrading to 16.y.z will be the safest. Other higher versions introduce ~3 minor errors.
• Thinking about upgrading typescript (to 5.y.z) is not an option for current Angular version. But if we will upgrade all components to 4.8.0 we will be able to consider type/node 18.y.z/20.y.z.

As the safest option I would go on 16.y.z, what do you think?