Hi @lugehorsam - Thank you for your questions and interest. To answer your questions, I will expand a little.
(1) The plugin determines the Unity installation path based on the default installation directory or a configured path. The Unity version is identified by reading the
ProjectVersion.txt. Based on this information, the plugin can localize the Unity binary and thus use the Unity CLI to create builds.
(2) Please note that the main target group for this plugin are Nx users. With that being said, there are several reasons why it should be possible to use
nx serve to run the server:
- It does not require Docker to be installed.
- There is no need for a
docker-compose.yml in the repository, which reduces the configuration effort.
- Using Docker for serving is atypical within the Nx ecosystem.
Moreover, the task runners of the Nx plugin enable Nx to build, test, and deploy projects selectively. For example, the command
nx affected:build smartly identifies and builds only those projects that have undergone changes, while also taking dependencies into account. This feature is particularly useful for the CI/CD pipeline of a monorepo, ensuring efficiency and resource optimization.
Additionally, integrating Nakama into an Nx monorepo allows for uniform project configurations. You can set up different environments, such as
production, with each project having tailored options. For example,
nx serve nakama-server -c development could use
nx serve nakama-server -c production would use
production.yml. This functionality extends to build tasks and the
affected command. For instance, executing
nx affected:build -c production not only compiles the source but also automatically copies the
production.yml file to the distribution folder.
To @mofirouz - I appreciate your openness to community contributions. What do you think about providing the Nakama binaries via NPM? Since Nx is also provided via NPM, this could significantly simplify Nakama’s installation for Nx users, but also for TypeScript developers.
Upon further reflection, I think automatically downloading the Nakama is not that essential. As an alternative, the plugin could prompt the user to provide the path to the Nakama binary and direct the user to the releases page. The obvious downside is that this approach would require either including the binary in the repository or ensuring it’s installed on each developer’s machine at a consistent path or configured individually. However, this won’t be a deal breaker for the plugin.
Looking forward to your thoughts and feedback.