Structure of repository/framework

[ondrowan]

I started to play a bit with Lime as part of research about JS gaming frameworks. I'm trying to create very simple game with Django on backend. My path for javascript files is /static/js/. Right now, I clone Lime as submodule to this folder and run bin/lime.js for all the additional cloning. Right now, I see 2 problems with this approach:

• submodule - they are usually trouble, for one reason or another. It takes just one person to screw up the repo.
• lime.py being amongst static files - it is potential security risk and i'd feel much more comfortable if i had the file in root directory

I personally would split lime repo into multiple parts:

• framework itself
• demos (let's face it, most of the people will just want remove them anyway)
• lime.py + other utilities (I'll talk about that in a bit)

Main goal would be to split lime.py and create dependencies file and config for it. You could put Closure, Box2d etc into deps file in similarly to requirements.txt in pip. In config you could set default path for your JS libraries (in my case /static/js/) amongst other things (path of your real lime app etc).

So, if I wanted to install lime and its dependencies, I'd just download lime.py and its configs (let's call it limejs-utilities for example), change paths in config and run a simple command as it's done now. I think it'd be more comfortable for users this way. Although, there would still be need for submodule (lime-utilities), I'd be much more comfortable having just few files this way instead of whole framework.

Now why I don't just do most of this manually right now? I could copy lime.py to root, change paths in it and be happy, but it breaks submodule right away and I can't update limejs itself as easily afterwards. Maybe solution would be to just copy all files instead of creating submodule, but that isn't really as comfortable as it could be.

I'd be happy to participate with these changes if you people are ok with it.

[tonistiigi]

There is actually no need for the limejs main repo to exists inside your project. For example my dev environment looks like this that I have a separate git repo for every game(that only contains the game code) and a single limejs repo.

I always call the same lime.py for every project. All the project paths are just listed in bin/projects file (they are added to there automatically if you run lime.py from the project directory).

When game is complete the build version is also put in the projects repo and the deployment process doesn't require any limejs/closure dependencies any more.

I'm also concerned about over complicating things for new people. Current install process is meant to be as simple as possible, yet most of our support tickets are about getting things running.

[ondrowan]

That's pretty smart structure you described. I also didn't know about this project file and how powerful this build script is.

Talking about new people, is there any documentation for recommended project structure? Seems like something new people could be interested in. Just a simple description of Lime repo and some steps needed to create new project would do the trick. Perhaps making repo for documentation / guide could be a good idea, so you don't have to maintain it alone.

[MaliusArth]

The information on how to get started with limejs and how to create new projects can be found in the limejs/README.md.
But the repo does indeed lack of up-to-date documentation.
I would suggest a policy: PRs are only merged if all functions of the files of interest or at least the changed functions are annotated according to JSDoc which is also used in the Closure Compiler.
This policy paired with a platform like ReadTheDocs, for example, and documentation practically creates itself.