TypeScript Blog

How many years have you been doing this? How many hours have teams you've worked on spent configuring build pipelines? How many people have you seen to go other mentors or helpers in your org when they are setting up a new project? How many many times have you seen someone start from from nothing & be done in <1 hour?

This post feels like a trivialization of how complicated everything is, how complexly interlinked build systems are.

It also misses one of the biggest harms. It doesn't consider what a pain in the ass it is when the source/libraries you are consuming have already been downcompiled into lesser JS via someone elses perhaps-poorly configured build pipeline. I'd guess that >80% of TypeScript modules don't export ESM right now. TypeScript 4.7 is about two weeks old & it's the first time TypeScript and Node's ESM play well[1]. Because it all involves complex transpilation. How many modules do you think will get updated, ever?

You know what would be great? If we could just write code. If we didn't have to worry about build pipelines. If my toolchain could make what it would of other code, be it JS or JS+TypeScript Type Annotations or JS+Flow Type Annotations.

> "For frontend usually you literally don't configure anything, Next.JS, CRA, or whatever" "For backend node, you simply edit a couple of lines in the package.json"

The amount of dissympathy for the real complexity here, for how hard a couple specific projects have worked to make things "just go" is…

> Typescript has always included extensions in the output of imports. When you used a bare TS file import without an extension it added a .js extension in the transpiled output. .js file extensions have always worked in Typescript (going back to 0.x days).

It was not. https://github.com/microsoft/TypeScript/issues/16577
There was proposal and PR, but It was rejected. When writing ESM in typescript, you need to import with .js extension.

>There's (luckily) no such thing as an "ESM variant" of Node and browsers will never have to know anything about the .mjs file extension. (Web servers will to make sure the present the right mime type, but that's a separate issue.) They just need ESM. I stand by accusing Node of doing the silly thing by adding the .cjs and .mjs file extensions. (I understand why they did it and mixed-module libraries were a thing that needed to exist until LTS support for ESM was well adopted, but we're past that transition phase, it wasn't that long of a transition phase, and in hindsight I think it still feels a little silly. Useful, but silly.)

There is absolutely such thing. Spec is either intentionally not being followed (babel) or it allows for host implementation to define some things (node.js, deno).

> but we're past that transition phase,

We are not. 99% of new projects use ESM with CommonJS resolution today!. Most codebases have no way to transition to ESM. It was a Herculean effort for typescript codebase to be migrated into ESM…

If you're happy with a single bundled file, another option is:

deno bundle 'https://esm.sh/@observablehq/plot' > plot.js

My browser development workflow looks somewhat like the following:

Imports / versions in importmap.json:

{
"imports":
{
"plot": "https://esm.sh/@observablehq/plot@0.6.6"
}
}

Code in app.js:

import * as Plot from "plot";
const plot = Plot.rectY(
{length: 10000}, Plot.binX(
{y: "count"},
{x: Math.random})).plot();
const div = document.querySelector("#myplot");
div.append(plot);

For development use dev.html:

<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8" />
<script type="importmap" src="./importmap.json"></script>
<script type="module" src="./app.js"></script>
</head>
<body>
<div id="myplot"></div>
</body>
</html>

Then you can then bundle with:

deno bundle --import-map=importmap.json app.js > bundle.js

And have as your prod.html:

<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8" />
<script type="module" src="./bundle.js"></script>
</head>
<body>
<div id="myplot"></div>
</body>
</html>

Note that `deno bundle` is deprecated. You can almost replace it with esbuild but it currently lacks builtin support for import maps:

deno run --allow-all https://deno.land/x/esbuild@v0.17.18/mod.js --bundle app.js --outfile=bundle.js. # errors, see:…

Why is taking out the part that actually checks the types at the developer's side a huge blessing?

Or if you are hoping to get the benefit of type checking in the browser itself (taking the same sweet time as tsc, but this time on every browser instead of once in the CI), then how long would you want to wait to be able to actually use the new typing functionality described in e.g. the latest TS annoucement? https://devblogs.microsoft.com/typescript/announcing-typescript-5-5/ .

Because it would take a while until that would then become the standard and then become available in every browser. And you still need to provide the JS versions, because not every browser is going to support TS.

In the meanwhile you could just keep using tsc just as before and get access to new functionality immediately.

(I imagine you could run tsc in the browser right now if you really wanted to.)

Short comment about the 'unknown' type: TypeScript 4.4 had me learning about it very recently, because 'unknown' has been made the default type in 'catch (error)' clauses [0]. So most of our code in 'catch' blocks suddenly didn't compile any more after an unsuspecting update of the TS version.

Which is a good thing, because in reviewing those I found several places where incorrect assumptions were being made about the type of error that would be caught.

(side note: TypeScript does not follow SemVer; they just promise to avoid breaking changes in Patch updates, but don't promise anything won't break in Minor updates [1])

[0]: https://devblogs.microsoft.com/typescript/announcing-typescript-4-4/#use-unknown-catch-variables

[1]: https://github.com/microsoft/TypeScript/issues/14116#issuecomment-280410804

We use sorbet pretty extensively. Overall it's been a net positive, but if you're coming from something like typescript, IMO it's far, far behind in terms of usability.

You can get pretty good value from things like intellisense in your editor, knowing that the constant you're referencing or method you're calling exists etc, but most libraries have no typings in sorbet-typed (beyond `T.untyped`).

The last post on Sorbet's blog was from 2022 https://sorbet.org/blog/, so I'm not sure how actively it's being developed. (compare that to typescript where you have a post every month https://devblogs.microsoft.com/typescript/)