rtsao

I've heard of `isolatedDeclarations` in TS 5.5, but this post left me with more questions than answers because it conflates so many distinct things (TS 5.5, Deno, JSR).

I'll try my best to break it down succinctly:

1) Historically, .d.ts generation is slow because it requires the full TypeScript type checker in order to correctly handle all cases (e.g. exported functions with inferred return types)

2) However, if types were to be fully explicit, then .d.ts generation could be performed without a full type checker (i.e. by a faster compiler via mere syntax transformation)

3) The isolatedDeclarations flag causes the TS compiler to trigger errors when any exports would require inference in order to generate .d.ts

4) Thus, the isolatedDeclarations flag can be used to guarantee compatibility with faster, simpler .d.ts generation using syntax-based transformation

5) A consequence of simpler .d.ts generation is that it can be trivially done in parallel, which can be helpful for large monorepos

Yarn 2.0 was ambitious, but in hindsight, it probably would have been better to make regular node_modules the default rather than pushing PnP and zero installs (and alienating most users in the process).

I think Yarn Berry with node_modules linker is strictly better than Yarn 1.0, whereas PnP and zero installs involve tradeoffs that might not be right for everyone. There's a lot of great design decisions in Berry that gets muddled with all the PnP-related discussion. I will say Maël deserves a lot of credit for driving corepack, which makes version control of package management totally seamless. It's always been a total nightmare but now it's shockingly easy.

The demonstrated software doesn't look too compelling (mostly floating 2D app windows), but I could see this becoming the ultimate learning/training tool. Interactive, step-by-step guides/instruction on how to do literally anything would be incredibly useful (play an instrument, vehicle maintenance, cooking, etc.)

If the hardware is sufficiently good, eventually the software will come, which is probably why this initially targeting the pro market. I'm skeptical the current frameworks make it easy enough to build quality AR apps, but hopefully the difficulty will go down eventually (maybe with the help of AI).

I recall many years ago Jonathan Hall (economist at Uber) describing a "traffic apocalypse" caused by empty self-driving cars flooding city streets. I think the notion was the operational cost of self-driving cars was so low that wasteful (empty car) usage would skyrocket without anyone directly paying the cost of time/road use. Today, the mean number of people per car on the road is at least 1, but with empty AVs that could plummet to <1.

I believe this scenario was discussed as an argument for congestion pricing, serving as a vital solution to the tragedy of the commons exacerbated by self-driving cars.

I think the fundamental issue plaguing virtually all forms of automatic release note generation boils down to the mismatch of audience. Commit messages and even pull request titles are tailored to be read and understood by other maintainers and contributors, who are likely to be familiar with internal details of the project. Clear and concise communication for this audience might mean using more specialized jargon or referencing implementation details.

By contrast, release notes are meant to be consumed by a much wider audience, who are chiefly concerned with the externally visible aspects of the project. Communication tailored to other maintainers (e.g. commits and PR titles) is rarely also optimal for this broader audience. This is why commit-based generated changelogs have a bad reputation: commits are meant for contributors—not customers—and thus tend to be useless.

This also explains why a good, dedicated CHANGELOG.md is usually so effective: unlike commits or PRs, it affords contribution authors a separate place to write for a broader, different audience. Another nice property of this method is the notes themselves within the CHANGELOG.md can be collaboratively reviewed and edited right within the context of the PR. This is a very helpful mechanism to ensure that release notes are high quality and to distribute the burden of writing release notes to those most familiar with the changes (as opposed to the person creating the release).

I think the ideal scenario is that on a per-PR basis, the "external" release notes are automatically scaffolded from existing metadata such as commits or PR titles (or even sophisticated means such as identifying which packages have changed or knowing if a breaking change has occurred as a result of type interface changes) which are later refined/edited during PR review. I think it would also be great if GitHub Releases themselves could go through a review process akin to PRs in order to help ensure high quality and facilitate collaborative writing of release notes.

I hope this doesn't alter the current GitHub npm package registry policy where all packages must be published under a scope corresponding to name of the owning GitHub user/org. The resulting increased transparency and clarity of ownership will be great for the JS ecosystem.

The existing npm ownership model is markedly less clear and has led to several problems, including the transfer of package publishing rights to bad actors without anyone being aware. On the whole, npm accounts and orgs were always just an unnecessary abstraction that obscured the actual provenance of software, of which GitHub is the de facto source.

Did you evaluate TOML and if so, what were the drawbacks you identified for the workflow use case?