packages/likec4/src/vite/vite-dev.ts (1)

31-31: ⚡ Quick win

Prefer Number.parseInt over global parseInt.

Modern JavaScript best practice is to use Number.parseInt for better clarity and to avoid potential global namespace pollution.

♻️ Proposed fix

-  const port = explicitPort ?? (env['HMR_PORT'] ? parseInt(env['HMR_PORT'], 10) : undefined)
+  const port = explicitPort ?? (env['HMR_PORT'] ? Number.parseInt(env['HMR_PORT'], 10) : undefined)

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@packages/likec4/src/vite/vite-dev.ts` at line 31, Replace the use of the
global parseInt when deriving port so it uses Number.parseInt for clarity and to
avoid global namespace usage; specifically update the expression assigning port
(which checks explicitPort and env['HMR_PORT']) to call
Number.parseInt(env['HMR_PORT'], 10) instead of parseInt, keeping the same
fallback/undefined behavior for explicitPort and missing HMR_PORT.

packages/likec4/src/vite/vite-dev.ts (3)

31-31: 💤 Low value

Consider using Number.parseInt for clarity.

While parseInt works correctly here, using Number.parseInt makes it explicit that you're calling the method from the global Number object, which is preferred in modern TypeScript codebases.

♻️ Optional refactor

-  const port = explicitPort ?? (env['HMR_PORT'] ? parseInt(env['HMR_PORT'], 10) : undefined)
+  const port = explicitPort ?? (env['HMR_PORT'] ? Number.parseInt(env['HMR_PORT'], 10) : undefined)

As per coding guidelines, use oxlint for linting (which flagged this via SonarCloud).

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@packages/likec4/src/vite/vite-dev.ts` at line 31, The variable declaration
for port uses the global parseInt; update it to use Number.parseInt for clarity
and consistency: change the parseInt call in the expression assigning port
(referencing variables explicitPort and env['HMR_PORT']) to
Number.parseInt(env['HMR_PORT'], 10) so the codebase explicitly uses the Number
namespace as per linting guidelines.

---

90-95: ⚡ Quick win

Enhance logging to distinguish port sources.

The current logging shows (explicit) only when hmrPort argument is provided, but doesn't distinguish between environment variable and auto-discovered ports. Users who set HMR_PORT environment variable won't see any source label, which could be confusing.

📊 Suggested logging enhancement

  const resolvedHmrPort = await resolveHmrPort(hmrPort, hmr)
  if (hmr && resolvedHmrPort !== undefined) {
-    const source = hmrPort ? ' (explicit)' : ''
+    let source = ''
+    if (hmrPort !== undefined) {
+      source = ' (via --hmr-port)'
+    } else if (env['HMR_PORT']) {
+      source = ' (via HMR_PORT env)'
+    } else {
+      source = ' (auto-discovered)'
+    }
     logger.info(`Enabling HMR: localhost:${resolvedHmrPort}${source}`)
     if (isInsideContainer()) {
       logger.info(k.yellow(`ensure port ${resolvedHmrPort} is published from container`))
     }

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@packages/likec4/src/vite/vite-dev.ts` around lines 90 - 95, The log for HMR
port should indicate whether the port came from an explicit hmrPort argument,
from the HMR_PORT environment variable, or was auto-discovered; update the
message around the hmr/resolvedHmrPort logic so the source string is set based
on hmrPort (explicit), process.env.HMR_PORT (env), or default/auto
(auto-discovered) and include that source label in the logger.info call that
currently references logger.info(`Enabling HMR:
localhost:${resolvedHmrPort}${source}`); keep the isInsideContainer() check and
its message unchanged.

---

24-36: ⚡ Quick win

Consider validating port numbers are in valid range.

The function accepts explicitPort without validating it's a valid port number (1–65535). Similarly, when parsing HMR_PORT from the environment, the result isn't range-checked. While invalid ports will cause Vite server startup to fail with an error, early validation would provide clearer feedback to users.

🛡️ Suggested validation

 export async function resolveHmrPort(
   explicitPort: number | undefined,
   hmrEnabled: boolean,
 ): Promise<number | undefined> {
   if (!hmrEnabled) {
     return undefined
   }
   const port = explicitPort ?? (env['HMR_PORT'] ? Number.parseInt(env['HMR_PORT'], 10) : undefined)
-  if (port) {
+  if (port !== undefined && !Number.isNaN(port)) {
+    if (port < 1 || port > 65535) {
+      throw new Error(`Invalid HMR port: ${port}. Must be between 1 and 65535.`)
+    }
     return port
   }
   return getPort({ port: portNumbers(24678, 24690) })
 }

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@packages/likec4/src/vite/vite-dev.ts` around lines 24 - 36, The
resolveHmrPort function currently accepts explicitPort and parses
env['HMR_PORT'] without range checks; validate both explicitPort and the parsed
envPort are integers between 1 and 65535 before returning them, and if either is
out of range throw a clear Error indicating the invalid value and whether it
came from explicitPort or HMR_PORT; keep the fallback to getPort({ port:
portNumbers(24678, 24690) }) unchanged and only call it when no valid
explicit/env port is provided.

packages/likec4/src/vite/vite-dev.ts (1)

100-100: ⚡ Quick win

Extract nested ternary for improved readability.

The nested ternary operator reduces readability. As per the static analysis hint, consider extracting this logic into a separate variable or using if-else statements.

♻️ Proposed refactor

   const resolvedHmrPort = await resolveHmrPort(hmrPort, hmr)
   if (hmr && resolvedHmrPort !== undefined) {
-    const source = hmrPort ? ' (explicit)' : env['HMR_PORT'] ? ' (env)' : ' (auto-discovered)'
+    let source = ' (auto-discovered)'
+    if (hmrPort) {
+      source = ' (explicit)'
+    } else if (env['HMR_PORT']) {
+      source = ' (env)'
+    }
     logger.info(`Enabling HMR: localhost:${resolvedHmrPort}${source}`)

As per coding guidelines, this aligns with the preference for clearer control flow over compact but harder-to-read expressions.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@packages/likec4/src/vite/vite-dev.ts` at line 100, The nested ternary
assigning source is hard to read; replace it by computing a descriptive string
with a small if/else or switch before the assignment so source is set from a
clear variable — use the existing identifiers hmrPort and env['HMR_PORT'] to
decide between " (explicit)", " (env)", and " (auto-discovered)" and then assign
that value to source (keep the symbol name source so downstream code is
unchanged).

✅ Autofix completed

packages/likec4/src/vite/vite-dev.ts (1)

107-116: ⚡ Quick win

Consider extracting the nested ternary for clarity.

The nested ternary at line 109 correctly determines the source of the HMR port, but could be made more readable by extracting it into separate if statements or a small helper. Additionally, using hmrPort !== undefined instead of the truthiness check would be more consistent with the logic in resolveHmrPort and more robust.

♻️ Proposed refactor

  const resolvedHmrPort = await resolveHmrPort(hmrPort, hmr)
  if (hmr && resolvedHmrPort !== undefined) {
-    const source = hmrPort ? ' (explicit)' : env['HMR_PORT'] ? ' (env)' : ' (auto-discovered)'
+    let source: string
+    if (hmrPort !== undefined) {
+      source = ' (explicit)'
+    } else if (env['HMR_PORT']) {
+      source = ' (env)'
+    } else {
+      source = ' (auto-discovered)'
+    }
    logger.info(`Enabling HMR: localhost:${resolvedHmrPort}${source}`)

As per coding guidelines, the repository prefers clarity in TypeScript code; extracting the nested ternary aligns with best practices for maintainable code.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@packages/likec4/src/vite/vite-dev.ts` around lines 107 - 116, The nested
ternary that builds the source label for HMR is hard to read and uses a
truthiness check on hmrPort; replace that expression by computing the source
string in a small local block (e.g., before the logger.info) using explicit
if/else or a helper so you can check hmrPort !== undefined, then fall back to
env['HMR_PORT'] and then to 'auto-discovered'; update the logger.info call that
uses resolvedHmrPort and source to use the new variable and keep the existing
isInsideContainer() branch as-is (references: resolvedHmrPort, hmrPort,
env['HMR_PORT'], logger.info, isInsideContainer()).