Say Goodbye to ‘../../../..’ in your TypeScript Imports

Don’t you hate writing import lines and not being sure how many dot-dot-slashes you need to get to the right place? Sure, you can look over at the project tree but there are so many files that you’ve got to scroll and scroll.

Oh no… Was that '../../../../' or '../../../../../'? [scrolls back down]. It drives me bananas.

Things are even worse if you restructure your project tree and some files move higher or lower. Or you copy-paste import sections between files that are at different levels in the project tree. Now your watch window is a sea of red.

But… it shouldn’t matter if your dependency is up four directories vs. five. Unfortunately, that’s just how module resolution works in Node.js.

Wouldn’t it be great if you could forget about relative paths entirely?

You could have the deepest, most complex project structure… bring it on.

Continue reading “Say Goodbye to ‘../../../..’ in your TypeScript Imports”

Say Goodbye to ‘../../../..’ in your TypeScript Imports

How to Fix Your Server-Side TypeScript Call Stack With webpack.BannerPlugin

TypeScript is a great language choice when you’re writing a large server-side Node.js project such as a universal React+Redux web application. However, debugging errors is challenging if you’re not set up for it properly.

Take an error call stack, for example…

An Insane Call Stack…

This is what TypeScript server-side errors can look like (without source map support):

Error: Big scary error message
    at Object.defineProperty.value (D:\BitBucket\Project\dist\server.js:2:8875)
    at t (D:\BitBucket\Project\dist\server.js:1:163)
    at Object.defineProperty.value (D:\BitBucket\Project\dist\server.js:22:2851)
    at t (D:\BitBucket\Project\dist\server.js:1:163)
    at Object.e.exports (D:\BitBucket\Project\dist\server.js:30:27387)
    at t (D:\BitBucket\Project\dist\server.js:1:163)
    at Object. (D:\BitBucket\Project\dist\server.js:21:29025)
    at t (D:\BitBucket\Project\dist\server.js:1:163)

Oh, I have an error on line 2… at column 8875 of a minified JavaScript bundle.

Thanks, log file.

Continue reading “How to Fix Your Server-Side TypeScript Call Stack With webpack.BannerPlugin”

How to Fix Your Server-Side TypeScript Call Stack With webpack.BannerPlugin

4 Quick Tips for Managing Many Sagas in a React-Redux-Saga App

Writing code any other way, once you’ve embraced the Redux-Saga way of implementing asynchronous operations, is difficult. Everything starts looking like a saga. You add a feature, and another, and another… and, soon, your project has 50+ sagas in it. (I just counted — my current project has 52 sagas).

But have you ever added a saga and jumped over to your app only to find that your saga doesn’t seem to be running? What’s going on? webpack --watch is running, the bundle was updated…

One downside to having a boatload of sagas is that each saga has to be registered with the redux-saga middleware in order to run. But fifty-two lines of repetitive code? I don’t think there’s a JavaScripter alive that wouldn’t cry foul over all that ‘boilerplate’.

Here’s how I managed to manage all those sagas without too much repetition.

Continue reading “4 Quick Tips for Managing Many Sagas in a React-Redux-Saga App”

4 Quick Tips for Managing Many Sagas in a React-Redux-Saga App