Using TypeScript and webpack alias: goodbye relative paths
This post shows how you can use TypeScript with webpack alias
to move away from using relative paths in your import
statements.
The TypeScript programming language.
View All TagsThis post shows how you can use TypeScript with webpack alias
to move away from using relative paths in your import
statements.
Most applications I write have some need for authentication and perhaps authorisation too. In fact, most apps most people write fall into that bracket. Here's the thing: Auth done well is a *big* chunk of work. And the minute you start thinking about that you almost invariably lose focus on the thing you actually want to build and ship.
2017 is drawing to a close, and it's been a big, big year in webpack-land. It's been a big year for ts-loader
too. At the start of the year v1.3.3 was the latest version available, officially supporting webpack 1. (Old school!) We end the year with ts-loader
sitting pretty at v3.2.0 and supporting webpack 2 and 3.
So, there you sit, conflicted. You've got a lovely build setup; it's a thing of beauty. Precious, polished like a diamond, sharpened like a circular saw. There at the core of your carefully crafted setup sits webpack. Heaving, mysterious... powerful.
A funny thing happened on the way to the registry the other day. Something changed in an npm package I was using and confusion arose. You can read my unfiltered confusion here but here's the slightly clearer explanation.
One of the most exciting features to ship with TypeScript 2.4 was support for the dynamic import expression. To quote the release blog post:
I've recently started a new role. Perhaps unsurprisingly, part of the technology stack is TypeScript. A couple of days into the new codebase I found a bug. Well, I say I found a bug, TypeScript and VS Code found the bug - I just let everyone else know.
That's how I was feeling on the morning of October 6th 2016. I'd been feeling that way for some time. The target of my concern? ts-loader. ts-loader is a loader for webpack; the module bundler. ts-loader allows you use TypeScript with webpack. I'd been a merry user of it for at least a year or so. But, at that point, all was not well in the land of ts-loader. Come with me and I'll tell you a story...
TypeScript 2.0 has shipped! Naturally I'm excited. For some time I've been using TypeScript to emit ES2015 code which I pass onto Babel to transpile to ES "old school". You can see how here.
I'm addicted to the ternary operator. For reasons I can't explain, I cannot get enough of:
I've been searching for a way to describe what the DefinePlugin actually does. The docs say:
Define free variables. Useful for having development builds with debug logging or adding global constants.
I'm a great lover of ES2015's Map
. However, just recently I tumbled over something I find a touch inconvenient about how you initialise a new Map
from the contents of an Array
in TypeScript.
TypeScript first gained support for tsconfig.json
back with the 1.5 release. However, to my lasting regret and surprise Visual Studio will not be gaining meaningful support for it until TypeScript 1.8 ships. However, if you want it now, it's already available to use in beta.
I'm a member of the Definitely Typed team - and hopefully I won't be kicked out for writing this. My point is this: .d.ts
files should live with the package they provide typing information for, in npm / GitHub etc. Not separately.
Sometimes, you just miss things. Something seismic happens and you had no idea. So it was with tsconfig.json
.
Have you heard the good news my friend? I refer, of course, to the shipping of TypeScript 1.4 and my favourite language feature since generics.... Union Types.
I previously attempted to migrate my Jasmine tests from JavaScript to TypeScript. The last time I tried it didn't go so well and I bailed. Thank the Lord for source control. But feeling I shouldn't be deterred I decided to have another crack at it.