InexorFlex: improve code structure to be editable

[a-teammate]

we have the problem that in order to modify our script code a lot of hassle is needed: Issue arises since we want to be more modular than our toolchain allows.

you clone https://github.com/inexorgame/inexor-flex somewhere, lets call it flex-git-folder (or you have it cloned already in the inexor-core/flex subdir) now you want to start to inexor-flex. so you npm install in the flex-git-folder subdirectory. but the pitfall is: the stuff in flex-git-folder/node_modules is not what you have in flex-git-folder/src and flex-git-folder/server!! Sidenote: (why is server not in src anyways??)

No, its the stuff it downloaded from npm.js! So if you modify e.g. flex-git-folder/src/releases/ReleaseManager.js you need to copy that file in flex-git-folder/node_modules/@inexorgame/releases/ then you need to restart inexor-flex to have it working.

The optimal case would be:

• you have a flex folder
• you install it: it installs all dependencies of all our inexorgame modules
• you start it: it executes the javascript in the src/ modules

and the holy grail would be that its hot-reloading:

• you modify a .js file in the src/ folder: its instantly relfected in the running inexor-flex instance.

---

Off topic 1: could we maybe find a better name for the inexor-flex API part? i mean: you have 2 windows open:

• in one: npm start -> starts inexor-flex
• in one is the flexAPIclient: inexor-flex its not really clear to me why these parts are not totally seperate, what do they share so that we want to keep them in one module? why isn't the thing we call the server and refer to with the name inexor-flex in the wiki the same as what we start with the command inexor-flex? it should be shouldn't it? Anyways we need names for that imo

[Fohlen]

Hey there. SInce there's been a lot of confusion about how to set up Inexor in a developer environment, I'll be going to write down my current workflow, and some explanation

Get it running with reload as a developer

npm un -g @inexorgame/inexor-flex # remove all previously installed occurences of inexor-flex
git clone https://github.com/inexorgame/inexor-flex.git
cd inexor-flex && npm install
npm start # for starting
npm link # if you would like to "globally install" the module. to have it call-able via inexor-flex

Now if you are working on a module, let's say src/releases

cd src/releases
npm link
<- this will override your installation in inexor-flex local AND your global installation

If you're changing a file in the src/ releases folder from now on, it will "live reload", since the module already points at the module you specified.

Source structure

This is quiet simple

• src are all modules that provide functionality. Libraries. Functions. All sorts of stuff.
• server is the actual flex application. It glues together the src modules and starts an expressjs server with an API
• server also contains runtime functionality, such as the path util to determine the paths at runtime
• inexor-flex is our command-line "front-end". It's really only yargs backed wrapper around the API exposed by server. All you really do is call the endpoints there.

[a-teammate]

Thanks Fohlen :)

The mentioned setup does work for me in the slight modification that I have to: npm link @inexorgame/releases in the flex folder after npm linking in the src/releases folder

So maybe we could automate this, since its also hard to remember for each branch which modules you need to link, since theyre different from the lastly released version.

---

server also contains runtime functionality, such as the path util to determine the paths at runtime

sounds wrong imo, why are the other dependencies not runtime functionality?

so what about renaming the server to inexor-flex and make it use the api module?

The problem i see here is that the daemon "server" is what we call throughout the wiki "Inexor-Flex", but now "inexor-flex" is some command line utility to speak with the daemon in the background, which is "the server" (another server, not to be confused with our grpc server, the gameserver or the masterserver, or ..)

[aschaeffer]

... is some command line utility to speak with the daemon ...

That's what I call the "Command Line API" which is provided by Flex.

[Fohlen]

@a-teammate no. the seperation is there for good reason.

• src modules really only deliver logic and functionality. If you take a closer look, you'll see that we don't determine any service behavoir within these components. You could take a totally different server and assemble all the components with stuff from src

• the daemon you're speaking about is the inexor flex server We have different types of server here

• inexor-core's gRPC server

• inexor-core enet Server (the actual game server)

• inexor-flex which sits on top of gRPC <-- this is what the command line speaks to. This is what has the API

In the end all the lower level servers (gRPC, ENET) will be hidden for the user, and configuration to join to a server is handled by flex.

• a flex server can list one or more "actual" enet servers
• the flex server exposes stats
• if you want to join, you ask flex, and flex will tell you at which enet port to connect ( although this is not yet exactly specified )

[aschaeffer]

Note: npm un -g and npm up -g require root permissions for me

[Fohlen]

@aschaeffer you should use nvm for development. I did notice this as well that our current prestart script should not have a -g flag.

[a-teammate]

npm up -g got fixed.

still what would be cool here would be:

• scripts for linux and windows to link all src/ subfolders automatically or any other solution for people who want to edit flex and see their changes get applied instantly.

[Fohlen]

@a-teammate https://github.com/gruntjs/grunt-contrib-watch

Simply, grunt watch on src and server. If something changes, go to the next directory containing a package.json and run npm link

[Croydon]

Most information here are outdated. While moving to Yarn I restructured the parts of flex to be invidivual modules, which are getting automatically linked (yarn link).

This might make the goals here more easier to achieve.