search

HoukasaurusRex / boilerplate-express-ts-server

A Best Practices™️ Express.js and Typescript server with clustering and socket.io
https://perfect-express-ts-server.herokuapp.com/
MIT License
4 stars 1 forks source link

ECMAScript imports #3

Open TNieminen opened 4 years ago

TNieminen commented 4 years ago

Using these imports works perfectly well in a TS server, but these types of imports will only work on later versions of Node, which might not be available in all environments.

How does this repo seek to support ES modules in a non-ts Node env?

One example could be previously discussed Babel, but that can also cause complications as we have experienced in the past in the frontend and it should be put to question do we really need this added complexity. Not really taking a side here one way or another, but just posing the question that how should we weight in or have weighted in the pros and cons of babelifying the server (or other options considered)

HoukasaurusRex commented 4 years ago

It's worth shooting for. Having a compiled server provides a lot of benefits like using es-next while compiling to whatever node version our production env is using (so our dev env is closer to prod env) and trimming unnecessary comments and spaces to optimize delivery (if we use something like parcel, webpack, or ts-node). It's not integral to the soul of this project, but it's something you'll miss if you're already used to it hahaha

TNieminen commented 4 years ago

I'm not generally opposed to this, I do find newer features of node useful and can see the benefits of delivery optimisation, especially because it could be replicated to Lambdas where size is crucial.

I'm just asking myself is there a current pain this is solving? And if there are bigger pains that we should solve first? For instance if we improve our API server deployment from 5 minutes to 1 minute, does it really make difference in the grand scheme of things? The reason I'm sticking on this more than the other changes is that this is not just merely moving things around but is changing the project deployment fundamentally.

My gut feeling (which can ofc be wrong) concerning this change is that there will be a fair share of weirdness involved with it and a fair bit of obscure debugging ahead of us first to have it working on local MAC and Ubuntu and lastly on the server. So my pitch to this would be that yes, could definitely be considered, but it could be better to scope it out of the current refactor.

HoukasaurusRex commented 4 years ago

Luckily this is more related to the configuration of the node env than the project structure. It's entirely feasible to refactor a server to match this scheme without using ts-node or babel-node first, then deciding later to add it in if we want or not at all if we don't.