Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
jakebailey
searching Neon…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
7 ms
·
1.
▲
by
jakebailey
2mo ago
The compiler was written in TS; it wouldn't make much sense to compile TS to Wasm, only to have that same code run in the same interpreter as the JS code. And yes, threading was a big part of it. See also: https://devblogs.m
2.
▲
by
jakebailey
2mo ago
Hoping to start getting Wasm builds out soon; it's a little unclear what people want when they say "Wasm", because it could mean - LSP monaco - the API in the browser - the CLI in Wasm for platforms we couldn't build whi
3.
▲
by
jakebailey
2y ago
The automatic generation was mainly a step to help with manual porting, since it requires so much vetting and updating for differences in data layout; effectively all of the checker code Anders ported himself!
4.
▲
by
jakebailey
2y ago
This is specifically about the performance of the TypeScript toolchain (compiler, editor experience); the runtime code generated is the same. TypeScript is just JS with types.
5.
▲
by
jakebailey
3y ago
> Until trademark laws come into play, and you find yourself obligated by law to give up your domain username to a big corporation. This wouldn't be a big deal in practice (besides losing the domain). Domain usernames are just the c
6.
▲
by
jakebailey
3y ago
> One of my major gripes with the JS/TS ecosystem is that "explanations" are sorely lacking. See https://www.typescriptlang.org/tsconfig for the relevant documentation for tsconfig files. Tutorials are on
7.
▲
by
jakebailey
4y ago
Ah, sorry; I brainfarted and missed the ".ts" part. I was thinking of the ".js" extensions, which are required in newer resolution modes (but are supported in older ones, and therefore using the strictest mode produces t
8.
▲
by
jakebailey
4y ago
Sure, we don't bump according to semver, but it's hard to say that 5.0 _isn't_ a major release given how we used it as a way to get a bunch of breaking changes and cleanups in. It's a very opportune time as people will b
9.
▲
by
jakebailey
4y ago
"bundler" is definitely not going to be the right resolution mode for using Deno; you may be better served by using ESNext or Node16/NodeNext (the "strictest" mode, really). The "who should use this mode"
10.
▲
by
jakebailey
4y ago
There's a full page of API breaks: https://github.com/microsoft/TypeScript/wiki/API-Breaking-Ch... Then, a new error about the deprecations of ancient options to be removed in 5.5: https://git
11.
▲
by
jakebailey
4y ago
It's not perfectly cut and dry, but mostly. We still need to emit d.ts files for our public API, and the only thing that can do that is tsc, which will type check. But I tried my best to make the build have fast paths to minimize the d
12.
▲
by
jakebailey
4y ago
We are still type checking, it's just not needed as a dependency for our JS outputs. Type checking still happens in tests, and I have CI tasks and VS Code watch tasks which will make sure we are still type checking.
13.
▲
by
jakebailey
4y ago
No formatter would support having code indented like that at the top level for no reason, so that's not an option. Though, I have been looking into getting us to use a formatter, period (right now we don't). I didn't consider
14.
▲
by
jakebailey
4y ago
These days, it's tracked at https://github.com/microsoft/TypeScript/issues/27891 . I have a gameplan to drop this by another 7 MB (by turning our executables into ESM), probably for 5.0 as well if we deci
15.
▲
by
jakebailey
4y ago
I think it's the case that modules are the future; but the main focus of this change was not actually performance at all. We've been wanting to be able to dogfood the modules experience (used by most TS devs) for a long time. The
16.
▲
by
jakebailey
4y ago
This is as incremental as it really could be; the entire build had to change, all of the code needed to be unindented one level, etc. I have tested the merge conflict problem, and thanks to the way the PR is constructed (in steps), git actu
17.
▲
by
jakebailey
4y ago
Surprisingly, at least for this PR, solving merge conflicts turns out to not be too hard. By not squash merging it, we can have a single commit that unindents the codebase all in one go (and the commit is in the tree), which means that ever
18.
▲
by
jakebailey
4y ago
I miss the Piazza days... Thank you for the kind words!
19.
▲
by
jakebailey
4y ago
TS has some unique restrictions due to downstream patching of our package; my PR description briefly talks about this as something we can try to improve in the future. Minification absolutely would save a lot more size out of our package, b
20.
▲
by
jakebailey
4y ago
There are some key things here that maybe weren't clearly stated in my writeup. Firstly, the old codebase is TS namespaces, which compile down to IIFEs that push properties onto objects. Each file that declares that namespace is its ow