> 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 combo of you telling Bluesky "I intend to use this domain name" and then you placing a TXT record on the domain to prove you own it. If you want to change domains (or, are forced to), you just give them the new domain name and you set another TXT record (just like if you had set up a domain name as a username for the first time). The underlying DID is still yours.
> 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 the page, how-to guides abound on the wider internet (like the OP), and the linked TSConfig Reference and JSON Schema (used in code completion in IDEs) are together absolutely massive.
> But an explanation is missing! There is no official documentation about how different options interact to say: as I'm walking a file tree as the Typescript compiler, this is how I will interpret a certain file I encounter, what will be outputted, and how that will be interpreted by bundlers and browsers, especially in an ESM world.
The "theory" page describes TypeScript's perspective on modules. The "reference" page documents things from the "as I'm walking a file tree" perspective (among many other details). The "guides" page also provides recommendations for certain kinds of projects.
"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" section here I believe is still accurate: https://github.com/microsoft/TypeScript/pull/51669
> - allowImportingTsExtensions: Allow imports to include TypeScript file extensions. Requires '--moduleResolution bundler' and either '--noEmit' or '--emitDeclarationOnly' to be set.
To be clear, I'm not using tsc to build code for Deno. I've got module X which imports module Y, neither of which have any platform-specific dependencies. Right now if module X imports Y with the .ts extension, Deno can import X but tsc can't. If module X imports Y without the .ts extension, tsc can import X but Deno can't. With this compiler option, I should be able to include the .ts extension and allow both to (independently) import the same code
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 the most compatible code).
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 be forced to manually upgrade and acknowledge that something is changing.
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.
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 development loop as much as possible.
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 decide that Node versions older than 12 are worth dropping.
I'm curious on how to make such a change in such a large and living code base.
Did you consider _not_ re-indenting the entire code base and rely on the auto formatters of contributing people? Did you consider re-formatting parts of the code step-by-step, beginning with code that's not frequently changed?
Didn't know about the feature that ignores commits in git-blame, thank you for that.
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 doing it step by step, no, but I'm not sure how I would really achieve that effectively. The reality is that the bulk of PRs are submitted by the team, and it's straightforward to get everyone to get their code in before this change, pause merges, rebase, and then continue as normal. I'd rather go for the "rip the band-aid off" method.
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 every line has a clear path back to the current state of the main branch. (And crucially, we can make git blame not point every line to me...)
Potentially, an approach like this might be applicable to other changes; I have a commit in my stack which moves the old build system config to the new build system config's path (even though it's wrong), as git does a much better job understanding where the code is going if you help it.
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, but I was not willing to change that in this PR.
This wouldn't be a big deal in practice (besides losing the domain). Domain usernames are just the combo of you telling Bluesky "I intend to use this domain name" and then you placing a TXT record on the domain to prove you own it. If you want to change domains (or, are forced to), you just give them the new domain name and you set another TXT record (just like if you had set up a domain name as a username for the first time). The underlying DID is still yours.