Conversation
- Limited to Linux x86 on Node20 at the moment !
+ Everything documented in BUILD_EXECUTABLE.md
AI Explaination :
1. **Backend Bundling**:
- Created a `vite.backend.config.ts` to bundle the TypeScript backend into a single CommonJS file (`dist-api/index.cjs`). This resolves issues with ESM, top-level await, and complex `node_modules` structures when packaging with `pkg`.
- Dependencies are bundled into the executable (except for native modules), ensuring all assets and subpath imports work correctly.
2. **Integrated Frontend Serving**:
- Added `src/api/infra/StaticServer.ts` which uses `express` to serve the built Vite frontend from the bundled environment.
- Modified `src/api/index.ts` to automatically start this static server when running in a packaged environment or production mode.
3. **Dynamic Environment Loading**:
- Updated the `.env` loading logic in `src/api/index.ts` to look for the `.env` file in the same directory as the executable, satisfying the requirement for external configuration.
4. **Packaging Configuration**:
- Configured `@yao-pkg/pkg` (a maintained fork supporting Node 20) in `package.json`.
- Included the built frontend (`dist/**/*`) and the `uWebSockets.js` native binary (`.node` file) as assets in the executable.
5. **Build Scripts**:
- Added `npm run build:frontend`, `npm run build:backend`, and `npm run build:executable` to `package.json`.
6. **Fixes for Bundled Context**:
- Refactored `src/api/index.ts` to avoid top-level await, ensuring compatibility with the CommonJS bundle required by `pkg`.
- Applied a global fix for a `ReferenceError` (`targetMatch`) found in the `evilscan` dependency when running in strict/bundled mode.
- Also rework some of the logging messages
- At the moment, only compile for MacOS x86 - Add new runner to have the compiled package compress to save some size
Application is compiled using `yao-pkg/pkg`, caxa been tested in developpement of this work but isn't used in final workflow
Otherwise, the artifact is quite big
- Since the introduction of ESLint, a lot of error have been raised all over the application - Fixed code smell from the backend - Properly use logger (by giving the Object _inside_ the logger function instead of outside) - Add semi-colon everywhere - The introduction of GAMALESS is prone to create a lot of error (since the PlayerManager still need to be active, but without interaction with GamaConnector which still could be requested but undefined... Catch most error) - Make ESLint more flexible by allowing `any` type
|
|
To keep everything documented here :
It looks like the uWebSocket's native lib for Windows isn't packaged.... However it should since the packaging add all libs (will need to be fixed later to have small packages. This increase the size by 50~100Mo). @GuillaumeLeroy34 can you try to compile the app from Windows and see if the exe crash with the same error message please ?
|
|
Merged early because this PR brings also a lot of code cleanup (ensuring a more stable platform). However, I'd still like to have work continuing on this branch (to, at least, get the Windows build working) |




Pull Request
Checklist
Description
This PR allow generating single binary application of the webplatform, removing all the difficulties and technical troubles of installing the project.
This PR also adds some operational Github Actions to easily create releases compiling the platform, and trying to compile it on every commit to avoid regression on this.
Finally, this PR adds a lot of code cleanup, especially pro-actively catching a lot of bugs introduced with
GAMALESSFuture work
Since the binary can be ran without anything around, a lot of verification should be added to not have the application crashing instantly (like if the folder
learning-packagesisn't found).Also, this PR use
@yao-pkg/pkgto package the project, however the support for native Mac ARM is experimental and not used at the moment (making the packaged platform running with Rosetta 2), this will need to be updated