Base on information gathered from working on #247 and #248, we should at some point discuss the goals of Hapi-Typescript-React-Views vs other alternatives.
Issues with current setup
My opinion is that Typescript's main advantage over vanilla JS are,
1) compile-time error checking and,
2) enabling better IDE feedback.
However, Hapi-Typescript-React-Views runs its transpiler step at server runtime. This essentially defeats 1, since we'll only get errors at runtime. Just as critical, Hapi-Typescript-React-Views runs its own transpiler pipeline separate from what is configured through webpack, tsconfig.json, and npm. And as a consequence, my IDE won't report errors correctly either since it's basing it's checks on the the current project's configuration which is separate from what is defined in Hapi-Typescript-React-Views
Possible Solutions (both eliminate need for Hapi-Typescript-React-Views)
Go back to Hapi-React-Views, and not use Typescript for the views.
Transpile the TSX views through webpack, just like all the other ones in the project, except it outputs transpiled JS files which the Hapi server will load for the views.
Base on information gathered from working on #247 and #248, we should at some point discuss the goals of Hapi-Typescript-React-Views vs other alternatives.
Issues with current setup
My opinion is that Typescript's main advantage over vanilla JS are, 1) compile-time error checking and, 2) enabling better IDE feedback.
However, Hapi-Typescript-React-Views runs its transpiler step at server runtime. This essentially defeats 1, since we'll only get errors at runtime. Just as critical, Hapi-Typescript-React-Views runs its own transpiler pipeline separate from what is configured through webpack, tsconfig.json, and npm. And as a consequence, my IDE won't report errors correctly either since it's basing it's checks on the the current project's configuration which is separate from what is defined in Hapi-Typescript-React-Views
Possible Solutions (both eliminate need for Hapi-Typescript-React-Views)