Support launching FW Lite on Linux in the lexicon extension#2427
Conversation
|
Important Review skippedAuto incremental reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
📝 WalkthroughWalkthroughThe build task for the Platform.Bible lexicon extension now publishes FwLiteWeb separately for win-x64 and linux-x64 into distinct directories. The launch logic replaces the hardcoded Windows-only binary path with a helper that resolves the binary path based on the detected platform. ChangesCross-platform FW Lite build and launch
Estimated code review effort: 2 (Simple) | ~10 minutes Suggested labels: Suggested reviewers: Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ 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 |
|
@alex-rawlings-yyc Could you test out this pr? The |
|
@imnasnainaec everything seems to run. Build was successful and I was able to access the FW Lite page in my browser. |
Select the FwLiteWeb binary per platform instead of hardcoding the Windows exe behind a win32 guard, and publish self-contained win-x64 and linux-x64 builds so one extension package runs on both platforms. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
d6d33e2 to
1d68cfc
Compare
getFwLiteDataDir used the Windows-only USERPROFILE env var and hardcoded backslash separators. Removing the platform guard in launchFwLite exposed this on Linux, where launching the packaged backend would throw (no USERPROFILE) and, if worked around, write to garbled backslash paths. Pick the home env var by platform (HOME on Linux/Mac) and assemble all paths, including the msal.json auth cache, with the platform separator. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@alex-rawlings-yyc There was a non-trivial merge conflict to resolve. Would you mind confirming it still works on Linux? |
|
@imnasnainaec all appears to be well |
hahn-kev
left a comment
There was a problem hiding this comment.
Looks good to me. I do think we should use a path join helper if one is available.
The lexicon extension refused to start on anything but Windows:
launchFwLitehardcodedfw-lite/FwLiteWeb.exebehind awin32guard, andtask build-fw-litepublished only the host RID. FW Lite already ships on Linux and Platform.Bible runs on Ubuntu, so this makes the extension's embedded FwLiteWeb backend follow.createProcess.osData.platformand letlinuxthrough the guard. macOS stays unsupported pending MacOS dotnet publish results in NativeAOT error #1603.public/fw-lite/<rid>/, so one extension package bundles both platforms. This roughly doubles package size — the alternative from the issue is per-platform packages; happy to switch if that's preferred.createProcess.spawnchmods the command on POSIX before spawning (paranext-core PT-3250), which repairs the executable bit lost in the zip → extension-install path. Cross-publishing linux-x64 from a Windows host is fine because FwLiteWeb is plain self-contained (no NativeAOT/trimming/single-file).Notes for reviewers:
public/fw-lite/should delete that directory once; the new layout ispublic/fw-lite/{win-x64,linux-x64}and stale root-level output would still get copied into the package by webpack's CopyPlugin.USERPROFILE+ backslash path handling needs the Linux treatment too (issue point 2).Closes #2425
🤖 Generated with Claude Code
Devin: https://app.devin.ai/review/sillsdev/languageforge-lexbox/pull/2427