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
Author here. That's good feedback. Looks like that part of my article is a bit confusing and I've updated the phrasing a little to hopefully make it less so.
You're spot on with all of your points. The isolated declarations feature forces your code to be written in a way that creating the .d.ts files is a mere exercise of stripping syntax and can be done easily without invoking the tsc compiler.
For runtimes like Deno which support running TS natively (disclaimer: I work for Deno) you never had to care about creating .d.ts files when publishing your package to any of the Deno registries: previously /x, now JSR. In the background though we've always tried to feed the tsc compiler in Deno something like .d.ts files though as it's quicker for type checking purposes.
This is all fully correct, which is why isolatedDeclarations is a nice feature... for authors of large Typescript projects. The tradeoff is to be more explicit on your public API surface so that you can reduce build times. That's great.
It really doesn't do the things the author thinks it does.
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've never forgotten a Hacker News comment about the same idea - might have predated Uber even. If parking costs increase, and self-driving cars can recharge cheaply, then we'll see them slowly navigating streets en masse while waiting for their next gigs. Like a molasses taxi rank oozing around with no urgency.
As someone who mostly cycles to get around the city, I would love this situation. I could get around everywhere so quickly between all the car-tar without the fear of being killed by a careless human driver. But if this thought experiment teaches anything, it's that we should give public pathways over to non-car users way before we ever get to this stage. We've already gone way too far out of our way for cars. Make most roads bike/train/tram only and save one or two lanes max for delivery trucks and maybe buses.
I already had this experience where i had to wait 30 minutes for someone to come pickup a car. Driving it around was cheaper than parking it for 30 minutes
haha, I experienced this myself. My friend fell on some hard times, and it was actually a net financial gain for me to have him sleep on my couch and pay for his food, since he'd drive me to/pick me up from work in downtown Seattle and save me $30/day on parking (or 60+ minutes a day in crappy bus commuting)
At the same time you'll have a dramatic drop in car ownership (since it'll be far cheaper to be taxied), meaning less waste overall as each car is fully utilized for potentially dozens of people a day, rather than sitting on a concrete pad 20+ hours a day doing nothing but aging.
I think people are too optimistic about the personal car as taxi approach. For anyone with families, I’ll have car seats installed, often you have personal items which I guess I would have to remember to always lock in the trunk. You will have passengers make a mess in your car, smoke and vape, even have sex (no driver!), and then I’ll pick up my kids and take them to soccer on same seat?
If most cars on the road are taxis, this means a few things. 1) It'll be much cheaper than owning a car. 2) There will always be a car within a minute or two to pick you up when you're ready. 3) There will be cars of every configuration available, including ones with car seats for kids (although it's not a huge deal, my twin's car seats take less than a minute to install). 4) These cars will be checked daily, and if you do happen to get a dirty car, you can just report it and get another one in the next few minutes. They'll likely have cameras in the cars that will know if someones smoking or having sex in there, so not many folks will do it if they don't want to pay a huge fee or get banned from the service.
I think this would ultimately be for the best. If the streets clogged up so severely with traffic then the value of owning a car would drop precipitously. Even if car owners lobbied successfully to widen all the streets the traffic would just expand to fill the available capacity.
People would finally be forced to seek alternatives!
One thing I’ve learned is that unless the option absolutely disappears, people usually won’t search for alternatives when something goes to absolute shit. They’ll just complain and accept it.
It’s more likely that roads will be widened and traffic will grow to meet that supply than it is that cars start to go away. Cars only go away when governments announce near immediate bans.
Your assumption is correct. Those docks are all based on the Goodway DBD1100 [1]. When I was researching which dock to purchase myself, I came across this comprehensive list [2] of Thunderbolt docks which was super informative.
Uber | Senior Software Engineer | Web Platform | San Francisco
Help develop the foundation for all web applications at Uber! Our team builds and maintains the developer tools, infrastructure, and frameworks that underpin the broad web app ecosystem serving our users (riders, drivers, eaters, shippers, carriers, and our internal operations & logistics teams).
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.
There's also a substantial writeup on the architecture of esbuild in the repo [1]. It is definitely worth a read if you are interested in some of the inner workings of esbuild or are curious how various bundler features are implemented. High-quality, in-depth architectural docs for complex projects like this are exceptionally rare.
It's great to see more tools adopting tree-sitter [1].
Having a (fast) single tool that can accurately parse most commonly used programming languages is incredibly useful, but it requires the maintenance of dozens of grammars, which is difficult without a large community effort. Hopefully increased adoption means more accurate parsers and support for even more languages.
Tree-sitter powers syntax highlighting on GitHub.com and (soon) neovim and OniVim 2. Hopefully regex-based syntax highlighting is a thing of the past soon. If you haven't seen the Strange Loop conference talk on tree-sitter [2] yet, it's worth a watch.
I think a Prettier-like code formatter using tree-sitter would be cool, both in terms of potentially broader language support and native performance.
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