Fix .ts/.tsx UI overrides being silently ignored in Publisher and Devportal

[Shamly-Shanawaz]

Problem

.ts/.tsx files placed under <webapp>/override/src for Advanced UI Customization are silently ignored. The build completes with exit code 0 and emits no error or warning, so the missing override is very hard to detect. .js/.jsx overrides are applied correctly.

Related Issue : Fixes wso2/api-manager#5161

Root cause

loader.js performs the source/src → override/src substitution, but it is registered only on the /\.(js|jsx)$/ webpack rule. It is absent from the /\.tsx?$/ rule, so TypeScript modules bypass the substitution entirely and are compiled straight from source/src.

Fix

Register loader.js on the /\.tsx?$/ rule in both portals. It is listed after ts-loader so it runs first - webpack executes a use array bottom-to-top, substituting the override before TypeScript compiles it. This mirrors the ordering already used by the adjacent /\.(js|jsx)$/ rule.

• portals/publisher/src/main/webapp/webpack.config.js
• portals/devportal/src/main/webapp/webpack.config.js

The Admin portal is unaffected: no .tsx? rule, no ts-loader, no tsconfig.json, no override/ directory, zero TypeScript sources.

Behaviour change

Because override TypeScript is now genuinely compiled, it is also type-checked against the web app's tsconfig.json (strict mode). A .ts/.tsx file under override/src containing a type error previously built green because it was
never read, it will now fail the build with a TypeScript diagnostic. Nothing changes until the web application is next rebuilt.

Testing

Verified per portal by overriding a matched .tsx/.jsx pair with distinct sentinel strings and grepping site/public/dist/*.bundle.js:

	before	after
.tsx override sentinel	0	1
.jsx override sentinel (control)	1	1
original literal	present	absent

The .jsx control passing in both builds isolates the failure to the TypeScript path. Confirmed for build:prod and build:dev, and at rendered-UI level in a running server. Also confirmed a type-broken override .tsx now fails the build
(TS2322), substantiating the behaviour-change note.

[coderabbitai]

📝 Walkthrough

Walkthrough

The Devportal and Publisher webpack configurations now apply loader.js after ts-loader for TypeScript and TSX files.

Changes

TypeScript loader integration

Layer / File(s)	Summary
Extend TypeScript webpack loader chains portals/devportal/src/main/webapp/webpack.config.js, portals/publisher/src/main/webapp/webpack.config.js	Both TypeScript and TSX rules now add loader.js after ts-loader.

Estimated code review effort: 1 (Trivial) | ~5 minutes

Possibly related issues

• wso2/api-manager#5161 — Adds loader.js to the Publisher and Devportal TypeScript webpack rules to enable .ts and .tsx overrides.

Suggested reviewers: ashera96

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Title check	✅ Passed	The title clearly identifies the fix for ignored TypeScript UI overrides in the Publisher and Devportal applications.
Description check	✅ Passed	The description directly explains the TypeScript override issue, root cause, fix, behavior change, and testing.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud