provide a way to build/compile TypeScript while using the "paths" fea…

…ture (#55)

So, I had been writing all this TypeScript code without trying to convert to JavaScript and when it finally came time to make it work, things didn't work because I'm using the [`paths`](https://www.typescriptlang.org/docs/handbook/module-resolution.html#path-mapping) feature in TypeScript.

Some context, the feature makes it so that when writing TypeScript code, especially code that's broken down into lots of files like this is looking like it is, we don't end up with ugly include paths `"../../../foo"` when writing and looking at the code and we can use aliases. Naturally, since this is a top level feature in TypeScript, one would expect that when you compile from TypeScript to JavaScript, your code just works. But nope, it doesn't, this is when you dig deep into the madness that is the current JavaScript ecosystem. 

There's apparently lots of [angst](microsoft/TypeScript#26722) about this and [lots](microsoft/TypeScript#10866) of people begging the TypeScript team to fix this but alas, such sensible things are not allowed in the TypeScript, JavaScript ecosystem, everything has to be as complicated as it needs to be. Even when a language exists ***just to make it easier to write in another language and cannot be run without compiling to said other language, we'll make it impossible for you to actually run your code without introducing some other abstraction to deal with this***. The entire JS ecosystem is maddening.

[This comment](microsoft/TypeScript#26722 (comment)) did a pretty good job explaining the issue if one permalink is wanted. Meanwhile, [here's a response](microsoft/TypeScript#26722 (comment)) from someone on the TypeScript team. I actually have no idea what he's trying to say there. I guess it's just normal in TS/JS land for one to need so many layers of abstractions just to run your code. 

Here's [other](microsoft/TypeScript#26722 (comment)) [users](microsoft/TypeScript#26722 (comment)) explaining why the current state of things doesn't seem to make sense.

I can keep linking but hopefully, the issue makes sense now. [MS team discussed](microsoft/TypeScript#26722 (comment)) it and decided: "nope, we're not fixing this". We're just going to leave this to be broken and sticking with "JS is JS". **WHAT DOES THAT MEAN???**

I looked into a bunch of solutions and they all seemed flawed:
* [module-alias](https://www.npmjs.com/package/module-alias): it says, don't use it for things that will eventually be libraries and involves duplicating the aliases from tsconfig.json into package.json. AND, also requires adding at each entry point of the app: `require('module-alias/register')` so would be needed for `graphql`, `api`, `async`, etc endpoints, won't necessarily work with codgen.
* [tsmodule-alias](https://www.npmjs.com/package/@momothepug/tsmodule-alias), lots of the same issues but different and  even more code needed to setup.
* [tspm](https://github.com/ef-carbon/tspm). hasn't been updated in 2+ years and [didn't work](0537e92). Note: webpack trials got hooked into that.
* [tspath] (https://www.npmjs.com/package/tspath). Also hasn't been updated in 2+ years. Thought I tried it but can't find the trial ¯\_(ツ)_/¯
*[webpack] (https://webpack.js.org/). This is the one I had the most success with and even had it working. Except it needed a lot more configuration and didn't seem ideal. I'm sure If I knew webpack better, I could get it working but there wasn't anything obvious that did everything I wanted, some of which were:

  - one output file for each input file
  - readable JS code without that much cruft
  - each file not necessarily being a bundle and being executable which is what I could get working with webpack. It just didn't seem like the right tool for the job. 
  - didn't have to copy dependent files e.g. database.yml files
I [started playing](50c1ef6) with [externals](https://webpack.js.org/configuration/externals/) to solve the problem but it just didn't seem right *and* I couldn't get it to work quickly so I moved on.

This approach uses the [TypeScript compiler API](https://github.com/microsoft/TypeScript/wiki/Using-the-Compiler-API#customizing-module-resolution) to read the `tsconfig.json` file for the paths and then do 2 things based on that:
1/ tell the compiler where to find each file by resolving the path names based on where they should be in the filesystem
2/ change the code generated to reference where the generated file should be instead of rendering useless things like "ent/schema" which don't actually refer to any file in the filesystem.

This works for where we are today but still needs a lot of work. Only works assuming simple cases, assumes there's only one path in the list, doesn't fallback accurately etc.
Longterm, this needs to be abstracted away into its own repo, made into an npm module, have lots of tests and ensure that it supports all the features from https://www.typescriptlang.org/docs/handbook/module-resolution.html#path-mapping but we're not there yet.

Also needs to support things like integrations with `jest` and other tools so there's not as much duplication happening all over the place like what we had at https://github.com/lolopinto/ent/blob/webpack/ts/examples/simple/jest.config.js#L1 in the `webpack` implementation.

.gitignore

@@ -1,3 +1,4 @@
 *.pyc
 *.code-workspace
 node_modules
+dist