By merely having a build phase in the life cycle of an application, we can do a number of things to ease our concerns. We can create config files for different environments, allowing for the different setups or variable inclusions based on environment. This can be done a number of different ways, such as keeping different
.env files containing their respective values or having a
config.js file which resolves an object with its respective variables through a single object interface. Whichever route you take, having this as a pluggable constant in your application helps take the guesswork out of things.
We can also abbreviate or mock different integrations or even down to the function level, for the purposes of testing. A testing environment is after all just another environment. This makes scaffolding a bit more self-explanatory as well, thankfully. Most test runners, such as jest, flag the node environment variable (a la
test during its run, so setting your testing configuration as just another environment is not only well supported, but desirable.
Some of the key side benefits to static typing in your work flow seem to come in a couple of flavors.
node_modules, as well as a type-ahead completion suggestions that are pretty solid. With static types in use, this also means that there is a far more intelligent display of what is expected. As someone who has done a large amount of Java work previously, this fills the gap of some of what I felt was missing when focusing more on front-end work, without Eclipse / IntelliJ IDEA.
Additionally, this greater and true understanding of imported code means that things like tree shaking and code splitting are far more powerful, as knowing explicitly, via named imports/exports, whether a function is needed in the built output is now legitimately definitive. This capability has obvious advantages regarding breaking apart modern front-end heavy builds and pushing an increasingly aware amount of what’s needed “down the pipes” to the user based on things like which page they’re on or whether or not they’re even logged into a valid session.
Over the last year, I’ve been increasing my use of TypeScript in my day-to-day work and have considered incorporating it more into my open source and dabbling projects. The best part of it all is that having created my own preferred flavor of a starter repo makes this easy to test in a branch and the use of my preferred build tool, Parcel, makes this extremely easy to setup and try out.
As mentioned above, adding TS to my starter repo was easy, almost too easy. When tooling does what it should, it can lead us to great places. Here’s how easy it was.