[WIP] Migrate Console app from webpack to vite#9885
[WIP] Migrate Console app from webpack to vite#9885JayaShakthi97 wants to merge 6 commits intowso2:nextfrom
Conversation
|
Important Review skippedDraft detected. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Path: .coderabbit.yml Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 10
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
apps/console/src/index.jsp (1)
364-370:⚠️ Potential issue | 🟠 MajorMissing
returnstatement ingetSuperTenantfunction.The function is missing a
returnkeyword on line 369, causing it to returnundefinedinstead ofstartupConfig.superTenantwhen no proxy is defined.Proposed fix
function getSuperTenant() { if (startupConfig.superTenantProxy) { return startupConfig.superTenantProxy; } - startupConfig.superTenant; + return startupConfig.superTenant; }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/console/src/index.jsp` around lines 364 - 370, The getSuperTenant function currently returns startupConfig.superTenantProxy when present but falls through without returning anything otherwise; update getSuperTenant to return startupConfig.superTenant in the fallback path by adding a return statement before startupConfig.superTenant so the function always returns the intended value (refer to function name getSuperTenant and properties startupConfig.superTenantProxy and startupConfig.superTenant).
🧹 Nitpick comments (2)
apps/console/VITE_MIGRATION_RUNTIME_SUMMARY.md (1)
77-88: Avoid concrete hashed filenames in the verification checklist.These paths will change on every build, so the checklist goes stale immediately. Use stable patterns or logical asset names instead, e.g.
ai-banner-background-white.*.svg.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/console/VITE_MIGRATION_RUNTIME_SUMMARY.md` around lines 77 - 88, Replace the hard-coded hashed filenames in the "Sample Media Paths to Verify" checklist with stable glob or pattern-based entries so the checklist stays valid across builds; update entries under the "Sample Media Paths to Verify" section (e.g., change lines like ai-banner-background-white.F6Tkc_Ta.svg to a pattern such as ai-banner-background-white.*.svg and similarly replace other concrete hashed names like account-lock.BdWVgDSt.svg, account-recovery-illustration.CEZNHcG4.svg, logo-mini.svg, logo-white.svg, app-icon-background.png, mobile-template.svg, salesforce.png with stable patterns or logical asset names) so the verification targets use wildcarded or canonical asset names instead of build-specific hashed filenames.apps/myaccount/VITE_MIGRATION_PLAN.md (1)
31-35: Call out/t/carbon.super/explicitly in the route-parity matrix.
tenant-aware pathsis still a bit too generic for a migration that rewrites base-path handling. Please include/t/carbon.super/myaccountin both the rewrite section and the runtime verification checklist so the super-tenant path is exercised explicitly. Based on learnings, "Enforce consistent tenant URL pattern across the codebase: all tenant-scoped paths use /t//, including carbon.super ... ensure tests cover /t// variations."Also applies to: 79-87
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/myaccount/VITE_MIGRATION_PLAN.md` around lines 31 - 35, Update the Dev server parity section and the runtime verification checklist in VITE_MIGRATION_PLAN.md to explicitly include the super-tenant path `/t/carbon.super/myaccount`: under the "Dev server parity" itemize list (the bullet that currently reads "base-path and tenant-aware rewrites") add `/t/carbon.super/myaccount` as an explicit rewrite case, and add a corresponding runtime verification entry that tests `/t/carbon.super/` variations (e.g., `/t/carbon.super/myaccount`) to ensure the base-path rewrite and deep-link fallback work; also mirror this explicit inclusion in the other referenced block (around the content at lines 79-87) so all tenant-scoped path guidance and test requirements call out `/t/<tenant>/` including `carbon.super`.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@apps/console/.env.local`:
- Around line 16-18: There are two consecutive blank lines after the
WDS_SOCKET_HOST entry in the .env snippet; edit the .env content to remove the
extra blank line so only a single blank line separates WDS_SOCKET_HOST from the
next section (i.e., collapse the two blank lines into one), keeping the
WDS_SOCKET_HOST line and surrounding content unchanged.
In `@apps/console/package.json`:
- Around line 181-182: Update the Vite-related dependencies in package.json to
the current stable versions: set "@vitejs/plugin-react" to 6.0.1,
"@vitejs/plugin-basic-ssl" to 2.2.0, "vite" to 8.0.1, "vite-tsconfig-paths" to
6.1.1, and "vite-plugin-svgr" to 4.5.0; after updating, run your package manager
install (npm/yarn/pnpm), run the test/build/dev scripts to catch breaking
changes, and adjust any vite or plugin config (vite.config.js/TS and React
plugin usage) per upstream changelogs if errors appear.
In `@apps/console/scripts/build/assemble-vite-build.js`:
- Around line 90-113: The catch currently swallows all evaluation errors and
returns "", which can mask malformed templates; change the catch in the
evaluate/ new Function block so it only returns the fallback value when the
expression is a simple buildOptions.<key> and that key actually exists on
options (i.e. when optionKeyMatch is truthy and
Object.prototype.hasOwnProperty.call(options, optionKeyMatch[1]) is true);
otherwise rethrow the original error (or throw a new Error) so the build fails
and unresolved placeholders are caught. Ensure you reference the evaluate/new
Function evaluation, the expression variable, the optionKeyMatch check, and the
options lookup when implementing this behavior.
In `@apps/console/scripts/build/resolve-build-mode.js`:
- Around line 41-55: The outDir currently hardcodes "build/console/app" even
when APP_BASE_PATH is set; update the logic that computes outDir (the same
branch using isStatic and isPreAuthCheckEnabled) to use the
resolvedAppBasePath/appBasePath value instead of the literal "app" so outDir
becomes `build/console/${resolvedAppBasePath}` when isStatic &&
isPreAuthCheckEnabled; refer to the existing symbols appBasePath,
resolvedAppBasePath, outDir, isStatic and isPreAuthCheckEnabled to locate and
adjust the conditional.
In `@apps/console/src/init/vite-entry.ts`:
- Around line 22-23: Remove the use of the any type on globalScope and
globalWithNodeAliases and use explicit intersection casting instead: drop ":
any" and assign globalScope by casting globalThis to the intersection type that
includes Buffer (typeof globalThis & { Buffer?: typeof Buffer }), and assign
globalWithNodeAliases by casting that globalScope to the intersection that adds
the Node alias (typeof globalScope & { global?: typeof globalThis }) or use
unknown with a narrow type assertion; update the declarations for the symbols
globalScope and globalWithNodeAliases accordingly.
- Line 19: Remove the deprecated import of "@babel/polyfill" from vite-entry.ts:
delete the line importing "@babel/polyfill" and if you need legacy polyfills
replace it with a modern alternative—either enable `@vitejs/plugin-legacy` for
browser support or import "core-js/stable" plus "regenerator-runtime/runtime"
explicitly; ensure existing Buffer/global alias setup in vite-entry.ts remains
unchanged.
In `@apps/console/vite.config.ts`:
- Around line 362-372: The lookup builds candidatePaths from
path.resolve(i18nBundlePath, relativeFilePath) and path.resolve(i18nMetaPath,
relativeFilePath) then finds existingPath by checking fs.existsSync and
fs.statSync; update this logic to reject path traversal by first normalizing and
resolving each candidate and then verifying the resolved path is a descendant of
its intended root (e.g., ensure
resolvedCandidate.startsWith(path.resolve(i18nBundlePath) + path.sep) or
similarly for i18nMetaPath) before calling fs.existsSync/fs.statSync and
returning existingPath; apply the same normalization-and-root-check fix to the
other similar block referenced (lines 429-438) that uses the same pattern.
- Line 139: Replace the loose any annotations with concrete types: change
middleware response parameters (e.g., the parameter named _response / response
in your middleware functions) from any to ServerResponse<IncomingMessage> and
add the corresponding import from 'http'; change the Rollup hook parameter named
assetInfo from any to PreRenderedAsset and import that type from 'rollup'; and
replace the deploymentConfig any type with Record<string, unknown> or a small
structured interface to reflect its shape. Locate the affected symbols
(_response/response parameters in your middleware functions, assetInfo in the
rollup hook, and deploymentConfig variable/type) and update their type
annotations and imports accordingly.
In `@features/admin.extensions.v1/extensions-manager.ts`:
- Around line 204-212: The code silently ignores missing content loaders (when
resolving contentModuleLoader from identityProviderTemplateContentModuleMap or
the other module map) leaving raw path strings in content; change the logic in
the blocks that reference contentModuleLoader and
identityProviderTemplateContentModuleMap so that if contentModuleLoader is falsy
you fail fast: throw an Error (or call a fail-fast helper) that includes the
unresolved module path (the original value) and a clear message, rather than
silently skipping assignment to content[key]; keep the successful path using
lazy(contentModuleLoader) unchanged.
- Around line 44-51: The glob module maps currently use Promise<any>; replace
those with explicit generic loader types and specific module-export interfaces:
define e.g. a ModuleLoader<T> = () => Promise<{ default: T }>, then type
applicationTemplateContentModuleMap and identityProviderTemplateContentModuleMap
to load the component type you expect (e.g., React.ComponentType or a specific
TemplateComponent interface) and type applicationTemplateResourceModuleMap and
identityProviderTemplateResourceModuleMap to load the resource shape (e.g.,
TemplateResource or IdentityProviderResource interfaces). Update any code that
imports from these maps (references around applicationTemplateContentModuleMap,
identityProviderTemplateContentModuleMap, applicationTemplateResourceModuleMap,
identityProviderTemplateResourceModuleMap and their usages at the later lines
called out) to use the new typed ModuleLoader<T> so no Promise<any> remains.
---
Outside diff comments:
In `@apps/console/src/index.jsp`:
- Around line 364-370: The getSuperTenant function currently returns
startupConfig.superTenantProxy when present but falls through without returning
anything otherwise; update getSuperTenant to return startupConfig.superTenant in
the fallback path by adding a return statement before startupConfig.superTenant
so the function always returns the intended value (refer to function name
getSuperTenant and properties startupConfig.superTenantProxy and
startupConfig.superTenant).
---
Nitpick comments:
In `@apps/console/VITE_MIGRATION_RUNTIME_SUMMARY.md`:
- Around line 77-88: Replace the hard-coded hashed filenames in the "Sample
Media Paths to Verify" checklist with stable glob or pattern-based entries so
the checklist stays valid across builds; update entries under the "Sample Media
Paths to Verify" section (e.g., change lines like
ai-banner-background-white.F6Tkc_Ta.svg to a pattern such as
ai-banner-background-white.*.svg and similarly replace other concrete hashed
names like account-lock.BdWVgDSt.svg,
account-recovery-illustration.CEZNHcG4.svg, logo-mini.svg, logo-white.svg,
app-icon-background.png, mobile-template.svg, salesforce.png with stable
patterns or logical asset names) so the verification targets use wildcarded or
canonical asset names instead of build-specific hashed filenames.
In `@apps/myaccount/VITE_MIGRATION_PLAN.md`:
- Around line 31-35: Update the Dev server parity section and the runtime
verification checklist in VITE_MIGRATION_PLAN.md to explicitly include the
super-tenant path `/t/carbon.super/myaccount`: under the "Dev server parity"
itemize list (the bullet that currently reads "base-path and tenant-aware
rewrites") add `/t/carbon.super/myaccount` as an explicit rewrite case, and add
a corresponding runtime verification entry that tests `/t/carbon.super/`
variations (e.g., `/t/carbon.super/myaccount`) to ensure the base-path rewrite
and deep-link fallback work; also mirror this explicit inclusion in the other
referenced block (around the content at lines 79-87) so all tenant-scoped path
guidance and test requirements call out `/t/<tenant>/` including `carbon.super`.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yml
Review profile: CHILL
Plan: Pro
Run ID: 4d183421-41e8-476c-b362-fb5a50118f08
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (19)
apps/console/.env.localapps/console/VITE_MIGRATION_RUNTIME_SUMMARY.mdapps/console/package.jsonapps/console/project.jsonapps/console/scripts/build/assemble-vite-build.jsapps/console/scripts/build/resolve-build-mode.jsapps/console/scripts/post-build.jsapps/console/src/auth.htmlapps/console/src/home.jspapps/console/src/index.htmlapps/console/src/index.jspapps/console/src/index.tsxapps/console/src/init/vite-entry.tsapps/console/tsconfig.jsonapps/console/vite.config.tsapps/console/webpack.config.tsapps/myaccount/VITE_MIGRATION_PLAN.mdfeatures/admin.extensions.v1/extensions-manager.tsmodules/forms/src/forms.tsx
💤 Files with no reviewable changes (1)
- apps/console/webpack.config.ts
|
|
||
|
|
||
|
|
There was a problem hiding this comment.
Remove extra blank lines.
Static analysis detected two consecutive blank lines (lines 17-18) after WDS_SOCKET_HOST. One blank line is sufficient for separating sections.
Proposed fix
WDS_SOCKET_PORT=9001
WDS_SOCKET_HOST=localhost
-
-
# ----------------------------------------------------------------------------------📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| WDS_SOCKET_PORT=9001 | |
| WDS_SOCKET_HOST=localhost | |
| # ---------------------------------------------------------------------------------- |
🧰 Tools
🪛 dotenv-linter (4.0.0)
[warning] 17-17: [ExtraBlankLine] Extra blank line detected
(ExtraBlankLine)
[warning] 18-18: [ExtraBlankLine] Extra blank line detected
(ExtraBlankLine)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@apps/console/.env.local` around lines 16 - 18, There are two consecutive
blank lines after the WDS_SOCKET_HOST entry in the .env snippet; edit the .env
content to remove the extra blank line so only a single blank line separates
WDS_SOCKET_HOST from the next section (i.e., collapse the two blank lines into
one), keeping the WDS_SOCKET_HOST line and surrounding content unchanged.
| "@vitejs/plugin-basic-ssl": "^1.2.0", | ||
| "@vitejs/plugin-react": "^4.3.1", |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Check latest versions of Vite ecosystem packages
echo "Checking latest versions of Vite packages..."
# Check npm registry for latest versions
for pkg in "vite" "@vitejs/plugin-react" "@vitejs/plugin-basic-ssl" "vite-plugin-svgr" "vite-tsconfig-paths"; do
echo "Package: $pkg"
curl -s "https://registry.npmjs.org/$pkg/latest" | jq -r '.version // "Not found"'
echo "---"
doneRepository: wso2/identity-apps
Length of output: 289
🏁 Script executed:
cat -n apps/console/package.json | sed -n '175,215p'Repository: wso2/identity-apps
Length of output: 1739
Update Vite ecosystem dependencies to current stable versions.
The Vite-related dependencies are significantly outdated:
@vitejs/plugin-react: ^4.3.1 → 6.0.1 (2 major versions behind)@vitejs/plugin-basic-ssl: ^1.2.0 → 2.2.0 (1 major version behind)vite: ^5.4.8 → 8.0.1 (3 major versions behind)vite-tsconfig-paths: ^4.3.2 → 6.1.1 (2 major versions behind)vite-plugin-svgr: ^4.2.0 → 4.5.0 (minor patch behind)
Update these to current stable versions to ensure security patches and compatibility.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@apps/console/package.json` around lines 181 - 182, Update the Vite-related
dependencies in package.json to the current stable versions: set
"@vitejs/plugin-react" to 6.0.1, "@vitejs/plugin-basic-ssl" to 2.2.0, "vite" to
8.0.1, "vite-tsconfig-paths" to 6.1.1, and "vite-plugin-svgr" to 4.5.0; after
updating, run your package manager install (npm/yarn/pnpm), run the
test/build/dev scripts to catch breaking changes, and adjust any vite or plugin
config (vite.config.js/TS and React plugin usage) per upstream changelogs if
errors appear.
| try { | ||
| // Evaluate only template expressions against a controlled | ||
| // object shape. This supports legacy ternaries/concatenations in JSP/HTML | ||
| // while avoiding changes to native JSP scriptlets. | ||
| const evaluate = new Function("buildOptions", `return (${expression});`); | ||
| const value = evaluate({ | ||
| ...options | ||
| }); | ||
|
|
||
| if (value === undefined || value === null) { | ||
| return ""; | ||
| } | ||
|
|
||
| return String(value); | ||
| } catch (_error) { | ||
| // Fallback for simple key access if expression evaluation fails. | ||
| const optionKeyMatch = expression.match(/^buildOptions\.([a-zA-Z0-9_]+)$/); | ||
|
|
||
| if (optionKeyMatch && Object.prototype.hasOwnProperty.call(options, optionKeyMatch[1])) { | ||
| return options[optionKeyMatch[1]]; | ||
| } | ||
|
|
||
| return ""; | ||
| } |
There was a problem hiding this comment.
Don't swallow template rendering failures.
If a buildOptions.* expression is malformed or references a missing key, this catch block returns "". That bypasses the later unresolved-placeholder check and can ship broken src/href values instead of failing the build.
💡 Proposed fix
} catch (_error) {
// Fallback for simple key access if expression evaluation fails.
const optionKeyMatch = expression.match(/^buildOptions\.([a-zA-Z0-9_]+)$/);
if (optionKeyMatch && Object.prototype.hasOwnProperty.call(options, optionKeyMatch[1])) {
return options[optionKeyMatch[1]];
}
- return "";
+ return match;
}🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@apps/console/scripts/build/assemble-vite-build.js` around lines 90 - 113, The
catch currently swallows all evaluation errors and returns "", which can mask
malformed templates; change the catch in the evaluate/ new Function block so it
only returns the fallback value when the expression is a simple
buildOptions.<key> and that key actually exists on options (i.e. when
optionKeyMatch is truthy and Object.prototype.hasOwnProperty.call(options,
optionKeyMatch[1]) is true); otherwise rethrow the original error (or throw a
new Error) so the build fails and unresolved placeholders are caught. Ensure you
reference the evaluate/new Function evaluation, the expression variable, the
optionKeyMatch check, and the options lookup when implementing this behavior.
| const appBasePath = (env.APP_BASE_PATH && env.APP_BASE_PATH.trim()) || "app"; | ||
|
|
||
| const resolvedAppBasePath = appBasePath.replace(/^\/+|\/+$/g, ""); | ||
| const publicBase = isStatic && isPreAuthCheckEnabled | ||
| ? `/${resolvedAppBasePath}/` | ||
| : "/console/"; | ||
|
|
||
| return { | ||
| appBasePath: resolvedAppBasePath, | ||
| isExternalTomcat, | ||
| isPreAuthCheckEnabled, | ||
| isStatic, | ||
| outDir: isStatic && isPreAuthCheckEnabled | ||
| ? "build/console/app" | ||
| : "build/console", |
There was a problem hiding this comment.
Honor APP_BASE_PATH when computing outDir.
publicBase and appBasePath already follow the env value, but outDir is still hardcoded to build/console/app. With APP_BASE_PATH=foo, Vite emits .vite/manifest.json and bundles under build/console/app while assemble-vite-build.js reads from build/console/foo, so the rendered shell is missing its entry assets.
💡 Proposed fix
- const resolvedAppBasePath = appBasePath.replace(/^\/+|\/+$/g, "");
+ const resolvedAppBasePath = appBasePath.replace(/^\/+|\/+$/g, "") || "app";
@@
outDir: isStatic && isPreAuthCheckEnabled
- ? "build/console/app"
+ ? `build/console/${resolvedAppBasePath}`
: "build/console",🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@apps/console/scripts/build/resolve-build-mode.js` around lines 41 - 55, The
outDir currently hardcodes "build/console/app" even when APP_BASE_PATH is set;
update the logic that computes outDir (the same branch using isStatic and
isPreAuthCheckEnabled) to use the resolvedAppBasePath/appBasePath value instead
of the literal "app" so outDir becomes `build/console/${resolvedAppBasePath}`
when isStatic && isPreAuthCheckEnabled; refer to the existing symbols
appBasePath, resolvedAppBasePath, outDir, isStatic and isPreAuthCheckEnabled to
locate and adjust the conditional.
| * under the License. | ||
| */ | ||
|
|
||
| import "@babel/polyfill"; |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
Is @babel/polyfill deprecated and what is the recommended replacement for Vite?
💡 Result:
Yes, @babel/polyfill is deprecated. The official Babel documentation states it has been deprecated since Babel 7.4.0 in favor of directly including core-js/stable (and regenerator-runtime/runtime if needed for generators/async functions). The npm package confirms this and was archived in 2020. For Vite projects, Vite does not include polyfills by default; it only handles syntax transforms via esbuild/Oxc for modern browsers (default: Chrome/Edge >=111, Firefox >=114, Safari >=16.4). If polyfills are needed (e.g., for older browsers or specific features): - Manually import at entry point (replacement for @babel/polyfill): import 'core-js/stable'; import 'regenerator-runtime/runtime'; This is recommended in Vite discussions and Babel docs. - For automatic polyfills based on browser targets and usage, use the official @vitejs/plugin-legacy plugin. It generates polyfill chunks using core-js (via @babel/preset-env useBuiltIns: 'usage') for legacy/modern browsers. - External services like polyfill.io (via script tag) for runtime detection. Vite docs explicitly note: "Vite only handles syntax transforms and does not cover polyfills." Use plugin-legacy for legacy support or manual imports for targeted polyfills.
Citations:
- 1: https://next.babeljs.io/docs/babel-polyfill
- 2: https://www.npmjs.com/package/@babel/polyfill
- 3: Archive
@babel/polyfillbabel/babel#12541 - 4: Dev diary-we shall not import @babel/polyfill in vite projects vitejs/vite#2763
- 5: https://babeljs.io/docs/en/babel-polyfill/
- 6: https://vite.dev/guide/build
- 7: https://v6.vite.dev/guide/build
- 8: https://www.npmjs.com/package/@vitejs/plugin-legacy
- 9: https://vitejs.dev/config/build-options
- 10: https://main.vite.dev/guide/build
🏁 Script executed:
# Find vite configuration files
find . -maxdepth 2 -name "vite.config.*" -o -name "vite.config.ts" -o -name "vite.config.js"Repository: wso2/identity-apps
Length of output: 44
🏁 Script executed:
# Check the vite-entry.ts file for context
cat -n apps/console/src/init/vite-entry.ts | head -30Repository: wso2/identity-apps
Length of output: 1370
🏁 Script executed:
# Search for other polyfill references in the codebase
rg "@babel/polyfill|core-js|regenerator-runtime" --type ts --type tsx -iRepository: wso2/identity-apps
Length of output: 89
🏁 Script executed:
# Check package.json for polyfill dependencies
cat package.json | grep -A 5 -B 5 "babel\|polyfill\|core-js\|regenerator"Repository: wso2/identity-apps
Length of output: 2335
🏁 Script executed:
# Look for vite config in apps/console
find apps/console -name "vite.config.*" -type fRepository: wso2/identity-apps
Length of output: 89
🏁 Script executed:
# Check if webpack is used
find apps/console -name "webpack.config.*" -type fRepository: wso2/identity-apps
Length of output: 44
🏁 Script executed:
# Search for polyfill references with correct syntax
rg "@babel/polyfill|core-js|regenerator-runtime" apps/console -iRepository: wso2/identity-apps
Length of output: 191
🏁 Script executed:
# Check if `@babel/polyfill` is actually imported anywhere else
rg "import.*@babel/polyfill|from.*@babel/polyfill" apps/consoleRepository: wso2/identity-apps
Length of output: 123
🏁 Script executed:
# Look at the directory structure of apps/console
ls -la apps/console/src/init/Repository: wso2/identity-apps
Length of output: 365
🏁 Script executed:
# Check vite.config.ts to understand browser targets
cat -n apps/console/vite.config.ts | head -50Repository: wso2/identity-apps
Length of output: 2160
🏁 Script executed:
# Check apps/console package.json for `@babel/polyfill` version and all polyfill-related deps
cat apps/console/package.json | grep -E "@babel/polyfill|babel-polyfill|core-js|regenerator-runtime|@vitejs/plugin-legacy" -B 2 -A 2Repository: wso2/identity-apps
Length of output: 242
🏁 Script executed:
# Check if `@babel/polyfill` is referenced in tsconfig or any build configuration
rg "@babel/polyfill" apps/console --type jsonRepository: wso2/identity-apps
Length of output: 44
🏁 Script executed:
# Check if `@babel/polyfill` is in apps/console/package.json
cat apps/console/package.json | grep -i "babel\|polyfill\|core-js\|regenerator"Repository: wso2/identity-apps
Length of output: 103
🏁 Script executed:
# Check if `@babel/polyfill` is listed as dependency in root package.json
cat package.json | grep "@babel/polyfill"Repository: wso2/identity-apps
Length of output: 98
🏁 Script executed:
# View full vite.config.ts to see build configuration and browser targets
cat apps/console/vite.config.ts | tail -100Repository: wso2/identity-apps
Length of output: 3639
🏁 Script executed:
# Check what vite-entry.ts does and if the polyfill is necessary
cat -n apps/console/src/init/vite-entry.tsRepository: wso2/identity-apps
Length of output: 1460
Remove the deprecated @babel/polyfill import or replace with modern equivalent.
@babel/polyfill is deprecated since Babel 7.4.0. For Vite, this import is unnecessary—Vite handles syntax transforms for modern browsers and doesn't include polyfills by default. The current vite-entry.ts only sets up Buffer and global aliases, which don't require @babel/polyfill.
If polyfills are needed for legacy browser support, use @vitejs/plugin-legacy or manually import core-js/stable and regenerator-runtime/runtime (the latter is already a project dependency). Otherwise, simply remove the @babel/polyfill import.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@apps/console/src/init/vite-entry.ts` at line 19, Remove the deprecated import
of "@babel/polyfill" from vite-entry.ts: delete the line importing
"@babel/polyfill" and if you need legacy polyfills replace it with a modern
alternative—either enable `@vitejs/plugin-legacy` for browser support or import
"core-js/stable" plus "regenerator-runtime/runtime" explicitly; ensure existing
Buffer/global alias setup in vite-entry.ts remains unchanged.
| const globalScope: any = globalThis as typeof globalThis & { Buffer?: typeof Buffer }; | ||
| const globalWithNodeAliases: any = globalScope as typeof globalScope & { global?: typeof globalThis }; |
There was a problem hiding this comment.
Avoid using any type; use proper type definitions.
The coding guidelines prohibit using any. Define proper intersection types instead.
Proposed fix
-const globalScope: any = globalThis as typeof globalThis & { Buffer?: typeof Buffer };
-const globalWithNodeAliases: any = globalScope as typeof globalScope & { global?: typeof globalThis };
+const globalScope: typeof globalThis & { Buffer?: typeof Buffer } = globalThis as typeof globalThis & { Buffer?: typeof Buffer };
+const globalWithNodeAliases: typeof globalScope & { global?: typeof globalThis } = globalScope as typeof globalScope & { global?: typeof globalThis };As per coding guidelines: "Never use any; use proper types or unknown with type guards."
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@apps/console/src/init/vite-entry.ts` around lines 22 - 23, Remove the use of
the any type on globalScope and globalWithNodeAliases and use explicit
intersection casting instead: drop ": any" and assign globalScope by casting
globalThis to the intersection type that includes Buffer (typeof globalThis & {
Buffer?: typeof Buffer }), and assign globalWithNodeAliases by casting that
globalScope to the intersection that adds the Node alias (typeof globalScope & {
global?: typeof globalThis }) or use unknown with a narrow type assertion;
update the declarations for the symbols globalScope and globalWithNodeAliases
accordingly.
|
|
||
| server.middlewares.use(( | ||
| request: IncomingMessage, | ||
| _response: any, |
There was a problem hiding this comment.
🛠️ Refactor suggestion | 🟠 Major
🧩 Analysis chain
🏁 Script executed:
wc -l apps/console/vite.config.tsRepository: wso2/identity-apps
Length of output: 93
🏁 Script executed:
cat -n apps/console/vite.config.ts | sed -n '130,150p;190,210p;215,230p;335,350p;400,420p;500,520p'Repository: wso2/identity-apps
Length of output: 5589
🏁 Script executed:
head -50 apps/console/vite.config.tsRepository: wso2/identity-apps
Length of output: 1810
🏁 Script executed:
grep -n "import" apps/console/vite.config.ts | head -30Repository: wso2/identity-apps
Length of output: 1759
🏁 Script executed:
cat -n apps/console/vite.config.ts | sed -n '219,230p;339,345p;407,413p'Repository: wso2/identity-apps
Length of output: 1258
🏁 Script executed:
# Check for any type definitions or interfaces in the file
rg "type|interface" apps/console/vite.config.ts | head -20Repository: wso2/identity-apps
Length of output: 801
🌐 Web query:
Vite middleware response type ServerResponse Node.js
💡 Result:
In Vite, middleware for the development server (via configureServer hook or vite.middlewares) follows the Connect/Express signature: (req: http.IncomingMessage, res: http.ServerResponse, next: => void) => void. The ServerResponse type is Node.js's built-in http.ServerResponse from the node:http module. ViteDevServer.middlewares is typed as Connect.Server, a Connect app instance compatible with Node.js http servers and Connect-style frameworks. Custom middlewares added via server.middlewares.use or configureServer(server) receive http.ServerResponse as the second parameter. Example usage: import http from 'node:http'; import { defineConfig } from 'vite'; export default defineConfig({ server: { configureServer(server) { server.middlewares.use((req: http.IncomingMessage, res: http.ServerResponse, next) => { // Custom logic if (req.url === '/custom') { res.setHeader('Content-Type', 'text/plain'); res.end('Custom response'); return; } next; }); } } }); This is consistent across Vite versions, including SSR middleware mode where vite.middlewares is used in Express/Koa apps with the same Node.js http types.
Citations:
- 1: https://vite.dev/guide/ssr
- 2: https://v6.vite.dev/guide/api-javascript
- 3: https://vite.dev/guide/api-javascript
- 4: https://dev.to/brense/vite-dev-server-adding-middleware-3mp5
- 5: https://registry.npmjs.org/%40vavite%2Fconnect
- 6: https://main.vite.dev/guide/api-javascript
- 7: Custom express middleware support vitejs/vite#6562
🌐 Web query:
Rollup AssetInfo type definition
💡 Result:
The Rollup AssetInfo type is used in plugin hooks like renderChunk for chunks and in assetFileNames/output functions as PreRenderedAsset. It provides metadata about emitted assets or chunks. For assets in generateBundle hook and OutputAsset: interface OutputAsset { type: 'asset'; fileName: string; source: string | Uint8Array; names?: string[]; originalFileNames?: string[]; } For PreRenderedAsset (used in assetFileNames): interface PreRenderedAsset { names: string[]; originalFileNames: string[]; source: string | Uint8Array; type: 'asset'; } For RenderedChunk (renderChunk hook, sometimes called chunkInfo with AssetInfo-like properties): interface RenderedChunk { type: 'chunk'; code: string; fileName: string; name: string; moduleIds: string[]; // additional properties like exports, facadeModuleId, etc. } AssetInfo specifically refers to the metadata object passed to naming functions or available in plugin contexts for assets/chunks, with properties like name, source, originalFileName(s). Rolldown (Rollup-compatible bundler) explicitly defines similar OutputAsset interface matching these properties. Official Rollup docs describe these fields in configuration options and JS API.
Citations:
- 1: https://rolldown.rs/reference/interface.outputasset
- 2: https://rollupjs.org/configuration-options/
- 3: https://rollupjs.org/javascript-api/
- 4: https://rollupjs.org/configuration-options
🏁 Script executed:
# Check if http.ServerResponse is imported or used elsewhere in the file
rg "ServerResponse" apps/console/vite.config.tsRepository: wso2/identity-apps
Length of output: 44
🏁 Script executed:
# Check for Rollup imports
rg "rollup|RollupOptions" apps/console/vite.config.tsRepository: wso2/identity-apps
Length of output: 119
🌐 Web query:
Node.js http.ServerResponse type import
💡 Result:
To import the http.ServerResponse type in Node.js with TypeScript, first ensure you have the Node.js type definitions installed via npm install --save-dev @types/node. Then import it from the node:http module (recommended for Node.js 16+): import type { ServerResponse } from 'node:http'; Or from the legacy http module: import type { ServerResponse } from 'http'; Example usage in a request handler: import { createServer } from 'node:http'; import type { IncomingMessage, ServerResponse } from 'node:http'; const server = createServer((req: IncomingMessage, res: ServerResponse) => { res.writeHead(200, { 'Content-Type': 'text/plain' }); res.end('Hello World'); }); The ServerResponse class extends stream.Writable and events.EventEmitter, and is passed as the second argument to the request listener. It is created internally by the HTTP server.
Citations:
- 1: https://nodejs.org/api/http.html
- 2: https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/node/http.d.ts
- 3: https://stackoverflow.com/questions/38941636/how-to-use-node-http-module-in-typescript
🌐 Web query:
Rollup PreRenderedAsset AssetInfo assetFileNames callback type
💡 Result:
In Rollup, output.assetFileNames is a configuration option for naming emitted assets. It can be a string pattern (default: 'assets/[name]-[hash][extname]') or a callback function that receives a PreRenderedAsset object and returns a string filename. The PreRenderedAsset interface (sometimes referred to as AssetInfo in older contexts or docs) has type: interface PreRenderedAsset { type: 'asset'; names: string[]; // array of asset names (replaces deprecated singular 'name') originalFileNames: string[]; // array of absolute paths to original source files (replaces deprecated singular 'originalFileName') source: string | Uint8Array; // asset content } This object is passed to the assetFileNames callback to dynamically generate filenames, e.g., based on extension derived from names[0], content hash, or original paths. Placeholders like [name], [hash], [extname] are supported in string patterns. Official Rollup docs confirm this structure for the callback parameter in output.assetFileNames, output.chunkFileNames (uses PreRenderedChunk), etc. Recent updates (Rollup 4.20+ via PRs #5596, #5686) added array support for multiple names/files due to deduplication. Example usage: output: { assetFileNames: (assetInfo: PreRenderedAsset) => { const ext = assetInfo.names[0]?.split('.').pop; return ext === 'css' ? styles/${assetInfo.names[0]} : assets/${assetInfo.names[0]}; } }
Citations:
- 1: https://rollupjs.org/configuration-options/
- 2: https://rolldown.rs/reference/interface.prerenderedasset
- 3: https://rolldown.rs/reference/outputoptions.assetfilenames
- 4: Add names and originalFileNames to assets rollup/rollup#5686
- 5: Add originalFIleName property to emitted assets rollup/rollup#5596
🏁 Script executed:
# Check if rollup is a dependency
rg "rollup" apps/console/package.json -A 5 -B 5Repository: wso2/identity-apps
Length of output: 44
🏁 Script executed:
# Check the actual usage of assetInfo to confirm type
cat -n apps/console/vite.config.ts | sed -n '506,520p'Repository: wso2/identity-apps
Length of output: 856
🏁 Script executed:
# Check if there are any other type imports that might help
cat -n apps/console/vite.config.ts | sed -n '19,30p'Repository: wso2/identity-apps
Length of output: 631
🏁 Script executed:
# Check if PreRenderedAsset or similar types are available from vite or rollup
python3 << 'EOF'
import json
import subprocess
# Try to find package.json to check if rollup/vite types are available
result = subprocess.run(['find', '.', '-name', 'package.json', '-type', 'f'],
capture_output=True, text=True, cwd='apps/console')
files = result.stdout.strip().split('\n')
# Get the main package.json
for f in files:
if 'node_modules' not in f:
print(f)
break
EOFRepository: wso2/identity-apps
Length of output: 76
🏁 Script executed:
# Check the root package.json for rollup/vite versions and dependencies
cat apps/console/vite.config.ts | grep -A 100 "rollupOptions" | head -30Repository: wso2/identity-apps
Length of output: 1163
🌐 Web query:
Vite defineConfig rollupOptions type PreRenderedAsset import
💡 Result:
In Vite, use defineConfig from 'vite' in your config file (vite.config.ts/js) for type safety and intellisense. The build.rollupOptions (now aliased as build.rolldownOptions but rollupOptions still works) accepts Rollup/Rolldown options that merge with Vite's internals. PreRenderedAsset is a Rollup/Rolldown type used in output.assetFileNames: string | ((assetInfo: PreRenderedAsset) => string). It has properties: names: string[], originalFileNames: string[], source: string | Uint8Array, type: 'asset'. To import in TypeScript: ts import type { PreRenderedAsset } from 'rollup'; // For Rollup types // Or potentially from Rolldown if using rolldownOptions // import type { PreRenderedAsset } from 'rolldown'; // Check Rolldown docs/version // In vite.config.ts import { defineConfig } from 'vite'; import type { PreRenderedAsset } from 'rollup'; export default defineConfig({ build: { rollupOptions: { output: { assetFileNames: (assetInfo: PreRenderedAsset) => { // Custom logic based on assetInfo.name, assetInfo.source, etc. if (assetInfo.name?.endsWith('.png')) { return 'images/[name]-[hash][extname]'; } return 'assets/[name]-[hash][extname]'; } } } } }); Vite provides Rollup types via intellisense with defineConfig. For full Rollup types in plugins/config, import from 'rollup'. Note: Vite 5+ uses Rolldown (Rust-based Rollup replacement) for builds, but types are compatible. Use category:people or check official docs for latest. Example usage from sources shows custom asset naming by file type/extension using the PreRenderedAsset parameter.
Citations:
- 1: https://rollupjs.org/configuration-options/
- 2: https://rolldown.rs/reference/interface.prerenderedasset
- 3: https://stackoverflow.com/questions/71180561/vite-change-ouput-directory-of-assets/71614411
- 4: https://khalidabuhakmeh.dev/manage-vite-assets-like-a-pro
🏁 Script executed:
# Check if there's any type re-exported from vite that we can use for assetFileNames
rg "PreRenderedAsset|AssetInfo" --type ts . | head -20Repository: wso2/identity-apps
Length of output: 44
🏁 Script executed:
# Check if deploymentConfig structure is documented anywhere
fd "deployment.config" . --type fRepository: wso2/identity-apps
Length of output: 672
🏁 Script executed:
# Check the actual deployment.config.json structure
cat apps/console/src/public/deployment.config.jsonRepository: wso2/identity-apps
Length of output: 50374
🏁 Script executed:
# Check if there's a type definition for deployment config in the codebase
fd "deployment" . --type f -e ts -e tsx | xargs rg "interface|type.*Deployment" | head -20Repository: wso2/identity-apps
Length of output: 420
Replace any type annotations with concrete types to comply with repo's type-safety guidelines.
The following parameters still use any and should be typed:
- Lines 139, 221, 342, 409: Middleware
responseparameters →ServerResponse<IncomingMessage>(import from 'http') - Line 509: Rollup's
assetInfoparameter →PreRenderedAsset(import from 'rollup') - Lines 198-200:
deploymentConfig→Record<string, unknown>or a structured interface
Per coding guidelines: "Never use any; use proper types or unknown with type guards."
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@apps/console/vite.config.ts` at line 139, Replace the loose any annotations
with concrete types: change middleware response parameters (e.g., the parameter
named _response / response in your middleware functions) from any to
ServerResponse<IncomingMessage> and add the corresponding import from 'http';
change the Rollup hook parameter named assetInfo from any to PreRenderedAsset
and import that type from 'rollup'; and replace the deploymentConfig any type
with Record<string, unknown> or a small structured interface to reflect its
shape. Locate the affected symbols (_response/response parameters in your
middleware functions, assetInfo in the rollup hook, and deploymentConfig
variable/type) and update their type annotations and imports accordingly.
| const relativeFilePath: string = pathName.replace("/resources/i18n/", ""); | ||
| // Keep lookup order aligned with previous build pipeline: | ||
| // 1) module bundle output, 2) app-local generated meta file. | ||
| const candidatePaths: string[] = [ | ||
| path.resolve(i18nBundlePath, relativeFilePath), | ||
| path.resolve(i18nMetaPath, relativeFilePath) | ||
| ]; | ||
|
|
||
| const existingPath: string | undefined = candidatePaths.find((candidatePath: string) => { | ||
| return fs.existsSync(candidatePath) && fs.statSync(candidatePath).isFile(); | ||
| }); |
There was a problem hiding this comment.
Reject .. escapes before serving dev assets.
Both middlewares feed request-derived paths straight into path.resolve(). Requests like /resources/i18n/../../package.json or /libs/../../src/public/deployment.config.json can escape the intended roots and be served if the file exists. Resolve the candidate path, then verify it still stays under the allowed directory before reading it.
Also applies to: 429-438
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@apps/console/vite.config.ts` around lines 362 - 372, The lookup builds
candidatePaths from path.resolve(i18nBundlePath, relativeFilePath) and
path.resolve(i18nMetaPath, relativeFilePath) then finds existingPath by checking
fs.existsSync and fs.statSync; update this logic to reject path traversal by
first normalizing and resolving each candidate and then verifying the resolved
path is a descendant of its intended root (e.g., ensure
resolvedCandidate.startsWith(path.resolve(i18nBundlePath) + path.sep) or
similarly for i18nMetaPath) before calling fs.existsSync/fs.statSync and
returning existingPath; apply the same normalization-and-root-check fix to the
other similar block referenced (lines 429-438) that uses the same pattern.
| const applicationTemplateContentModuleMap: Record<string, () => Promise<any>> = | ||
| import.meta.glob("./application-templates/**/*.tsx"); | ||
| const identityProviderTemplateContentModuleMap: Record<string, () => Promise<any>> = | ||
| import.meta.glob("./identity-provider-templates/**/*.tsx"); | ||
| const applicationTemplateResourceModuleMap: Record<string, () => Promise<any>> = | ||
| import.meta.glob("./application-templates/**/*.json"); | ||
| const identityProviderTemplateResourceModuleMap: Record<string, () => Promise<any>> = | ||
| import.meta.glob("./identity-provider-templates/**/*.json"); |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Verify explicit `any` usage in the reviewed file.
fd 'extensions-manager.ts$' --exec rg -nP '\bany\b|Promise<any>|:\s*any\b' {}Repository: wso2/identity-apps
Length of output: 1109
Remove any from module-loader and module typings.
The module loaders use Promise<any>, violating the requirement to always use explicit type annotations without any. Replace with properly typed interfaces.
Suggested fix
-import { lazy } from "react";
+import { ComponentType, lazy } from "react";
@@
-const applicationTemplateContentModuleMap: Record<string, () => Promise<any>> =
- import.meta.glob("./application-templates/**/*.tsx");
-const identityProviderTemplateContentModuleMap: Record<string, () => Promise<any>> =
- import.meta.glob("./identity-provider-templates/**/*.tsx");
-const applicationTemplateResourceModuleMap: Record<string, () => Promise<any>> =
- import.meta.glob("./application-templates/**/*.json");
-const identityProviderTemplateResourceModuleMap: Record<string, () => Promise<any>> =
- import.meta.glob("./identity-provider-templates/**/*.json");
+type ContentModuleInterface = { default: ComponentType<unknown> };
+type ResourceModuleInterface = { default: unknown };
+
+const applicationTemplateContentModuleMap: Record<string, () => Promise<ContentModuleInterface>> =
+ import.meta.glob<ContentModuleInterface>("./application-templates/**/*.tsx");
+const identityProviderTemplateContentModuleMap: Record<string, () => Promise<ContentModuleInterface>> =
+ import.meta.glob<ContentModuleInterface>("./identity-provider-templates/**/*.tsx");
+const applicationTemplateResourceModuleMap: Record<string, () => Promise<ResourceModuleInterface>> =
+ import.meta.glob<ResourceModuleInterface>("./application-templates/**/*.json");
+const identityProviderTemplateResourceModuleMap: Record<string, () => Promise<ResourceModuleInterface>> =
+ import.meta.glob<ResourceModuleInterface>("./identity-provider-templates/**/*.json");
@@
-const contentModuleLoader: () => Promise<any> = applicationTemplateContentModuleMap[value];
+const contentModuleLoader: () => Promise<ContentModuleInterface> = applicationTemplateContentModuleMap[value];
@@
-const contentModuleLoader: () => Promise<any> = identityProviderTemplateContentModuleMap[value];
+const contentModuleLoader: () => Promise<ContentModuleInterface> = identityProviderTemplateContentModuleMap[value];
@@
-const resourceModuleLoader: () => Promise<any> = applicationTemplateResourceModuleMap[resource];
+const resourceModuleLoader: () => Promise<ResourceModuleInterface> = applicationTemplateResourceModuleMap[resource];
@@
- ? resourceModuleLoader().then((module: any) => module.default)
+ ? resourceModuleLoader().then((module: ResourceModuleInterface) => module.default)
@@
-const resourceModuleLoader: () => Promise<any> = identityProviderTemplateResourceModuleMap[resource];
+const resourceModuleLoader: () => Promise<ResourceModuleInterface> = identityProviderTemplateResourceModuleMap[resource];
@@
- ? resourceModuleLoader().then((module: any) => module.default)
+ ? resourceModuleLoader().then((module: ResourceModuleInterface) => module.default)Lines 44–50, 202, 208, 220, 230, 233, 238, 241.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@features/admin.extensions.v1/extensions-manager.ts` around lines 44 - 51, The
glob module maps currently use Promise<any>; replace those with explicit generic
loader types and specific module-export interfaces: define e.g. a
ModuleLoader<T> = () => Promise<{ default: T }>, then type
applicationTemplateContentModuleMap and identityProviderTemplateContentModuleMap
to load the component type you expect (e.g., React.ComponentType or a specific
TemplateComponent interface) and type applicationTemplateResourceModuleMap and
identityProviderTemplateResourceModuleMap to load the resource shape (e.g.,
TemplateResource or IdentityProviderResource interfaces). Update any code that
imports from these maps (references around applicationTemplateContentModuleMap,
identityProviderTemplateContentModuleMap, applicationTemplateResourceModuleMap,
identityProviderTemplateResourceModuleMap and their usages at the later lines
called out) to use the new typed ModuleLoader<T> so no Promise<any> remains.
| if (contentModuleLoader) { | ||
| content[ key ] = lazy(contentModuleLoader); | ||
| } | ||
| } else if (value.includes("identity-provider-templates")) { | ||
| const valueStripped: string = value | ||
| .replace(/^\.\/identity-provider-templates\//, "") | ||
| .replace(/\.tsx$/, ""); | ||
| const contentModuleLoader: () => Promise<any> = identityProviderTemplateContentModuleMap[value]; | ||
|
|
||
| content[ key ] = lazy(() => import(`./identity-provider-templates/${ valueStripped }.tsx`)); | ||
| if (contentModuleLoader) { | ||
| content[ key ] = lazy(contentModuleLoader); | ||
| } |
There was a problem hiding this comment.
Fail fast when a content module path is not found.
At Line 204 and Line 210, missing content loaders are silently ignored, leaving unresolved string paths in content. This can surface later as rendering/runtime failures with poor diagnostics.
Suggested reliability fix
if (value.includes("application-templates")) {
const contentModuleLoader: () => Promise<any> = applicationTemplateContentModuleMap[value];
- if (contentModuleLoader) {
- content[ key ] = lazy(contentModuleLoader);
- }
+ if (!contentModuleLoader) {
+ throw new Error(`Unknown application template content: ${value}`);
+ }
+ content[ key ] = lazy(contentModuleLoader);
} else if (value.includes("identity-provider-templates")) {
const contentModuleLoader: () => Promise<any> = identityProviderTemplateContentModuleMap[value];
- if (contentModuleLoader) {
- content[ key ] = lazy(contentModuleLoader);
- }
+ if (!contentModuleLoader) {
+ throw new Error(`Unknown identity provider template content: ${value}`);
+ }
+ content[ key ] = lazy(contentModuleLoader);
}🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@features/admin.extensions.v1/extensions-manager.ts` around lines 204 - 212,
The code silently ignores missing content loaders (when resolving
contentModuleLoader from identityProviderTemplateContentModuleMap or the other
module map) leaving raw path strings in content; change the logic in the blocks
that reference contentModuleLoader and identityProviderTemplateContentModuleMap
so that if contentModuleLoader is falsy you fail fast: throw an Error (or call a
fail-fast helper) that includes the unresolved module path (the original value)
and a clear message, rather than silently skipping assignment to content[key];
keep the successful path using lazy(contentModuleLoader) unchanged.
1 participant
Purpose
Related Issues
Related PRs
Checklist
Security checks
Developer Checklist (Mandatory)
product-isissue to track any behavioral change or migration impact.