Trails structure for large projects using transpiled languages

README.md

Sails and Trails current directory structures look like this:

/api/...
/config/...
/assets/...

The server executes code directly from the source code directory. It executes the same code files that are stored in version control.

When using compiled languages, we need to convert our TypeScript, CoffeeScript, ES2015, etc files to .js. Naively, we might add a few .gitignore rules:

api/**.js
config/**.js

However, this only works when our code is written entirely in .ts, .coffee, or anything not .js. However, for a big project, you'll probably go through a transition period where you mix .js with .ts or .es. You might always have some old code that stays in .js because no one ever touches it except for minor fixes. You want to version the .js files unless they were generated by a compiler, so our previous .gitignore rules aren't useful.

You probably only want to see source code in your IDE. If you wrote functionality.es, you don't want your IDE's file browser cluttered with functionality.js next to it.

Put source in /src, compiled code in /lib

It's simpler when you compile all your source code from a /src directory into a /lib directory. (or /out or /bin or whatever)

• /src can contain a mix of .js and non .js, all in version control.
• .js is copied from /src to /lib
• .es or .ts is compiled from /src to /lib
• The sails server runs /lib code at runtime.

Modified directory structure

/src/api/...
/src/assets/...
/src/config/...

Why /src? Why not compile /assets into /bin/assets?

Because it messes with relative paths. Admittedly, this isn't a huge problem, but it might bite you at some point. This code runs fine in /assets/foo.es but breaks when compiled into /bin/assets/foo.js.

console.log(require('../package.json').version);

However, the same code written for /src/assets/foo.es is fine.

console.log(require('../../package.json').version);