Ensure Cross-Platform Stability (Paths and CRLF)

[marcogomez-dev]

Is your feature request or improvement related to a problem?

Yes. This is a critical bug fix addressing two core cross-platform compatibility issues that prevented the framework from functioning correctly on Windows systems:

1. Broken Asset Resolution: Windows backslashes (\) in file paths caused component loading to fail, specifically affecting DHTML components like /login.
2. Corrupted JavaScript Output: Windows line endings (CRLF, or \r\n) introduced carriage return characters (\r) into compiled JavaScript function bodies, resulting in malformed syntax and runtime errors.

These issues occurred in the core asset serving and script compilation logic, rendering the framework unstable or unusable on Windows platforms.

---

Solution you'd like

Implement targeted fixes in the asset serving and script compilation modules to achieve robust cross-platform compatibility:

1. Normalize Asset Paths in serve.js: Convert all Windows backslashes (\) to POSIX forward slashes (/) during URL-to-path matching to ensure DHTML components load correctly.
2. Clean Line Endings in compiler.js: Strip carriage return characters (\r) from JavaScript expression bodies during template compilation to prevent syntax errors in the final output.

Proposed Code Changes

File	Changes	Rationale
packages/nuekit/src/cmd/serve.js	Path normalization in findAssetByURL.	Allows asset URL matching to succeed regardless of the platform's native path separator.
packages/nuedom/src/compiler/compiler.js	Strip \r from expr in compileJS.	Prevents Windows CRLF line endings from corrupting compiled JavaScript code.

1. packages/nuekit/src/cmd/serve.js

export function findAssetByURL(url, assets=[]) {
  return [...sysfiles, ...assets].find(asset => {
    // Normalize backslashes to forward slashes for comparison on Windows.
    return url.endsWith('.html.js') 
      ? asset.path && asset.path.replace(/\\/g, '/') == url.slice(1, -3) // <--- CHANGE
      : asset.url == url
  })
}

2. packages/nuedom/src/compiler/compiler.js

export function compileJS(js) {
  return js.replace(RE_FN, function(_, key, __, expr) {
    // Strip carriage returns (\r) to handle Windows CRLF, then normalize \n.
    const cleanExpr = expr.trim().replace(/\\r/g, '').replace(/\\n/g, '\n') // <--- CHANGE

    return key == 'script' 
      ? `${key}: function() { ${cleanExpr} \n\t\t}` // Use cleanExpr
      : `${key}: ${compileFn(expr, key[0] == 'h')}`
  })
}

---

Alternatives you've considered

1. Relying on path.normalize() for serve.js: Using Node's built-in path.normalize() might still revert paths to the native separator, failing the comparison against the URL which must use forward slashes.

   • Reason for rejection: The explicit regex replacement (/\\/g, '/') is the most reliable way to enforce the web-standard POSIX path for string comparisons.

2. Ignoring line endings in compiler.js: We could try to work around the corrupted JavaScript code, but this would lead to fragile and complex parser logic.

   • Reason for rejection: Stripping the problematic carriage return character (\r) at the source is the definitive solution to ensure clean, executable JavaScript output, regardless of the user's OS or Git settings.

---

Additional context

These fixes are critical for achieving a stable developer experience on Windows.

• Path Fix: The asset path fix in serve.js ensures that when a .html.js asset path is retrieved (which uses the native OS path separator on Windows), it is properly compared against the requested URL, resolving the component loading issue.
• Line Ending Fix: The compiler.js fix addresses a subtle but fatal issue where the \r character would cause a syntax error in the compiled output, effectively breaking component logic. Removing \r ensures the function body remains valid JavaScript.

Initial testing confirmed that DHTML components now load successfully, and no JavaScript compilation errors occur on Windows. Functionality on Linux/macOS remains intact.

---

Final note

This entire work, including the root cause analysis, the path normalization strategy, and the specific code changes, was designed and implemented with the assistance of an AI. While the solution addresses the identified cross-platform compatibility issues, it is crucial that these changes be thoroughly tested across all target platforms (Windows, Linux, macOS). Deep verification is required to ensure the robustness of the new path handling logic and line ending cleanup.