I also had an alternative design that would allow a framework / library to track when a promise it created (e.g. a network query) becomes the eventual result of a promise it receives (e.g. userland handler that triggers the network query). But that'd require a significant JS engine and spec change.
The approach we're taking is to forego native promises and thenables altogether, and use another object that represents an eventual result. I need to write up our design somewhere (it leverages some of the concepts for eventual send).
It's fragile in the face of some user code refactors too. Anything that introduces a tick before these trapping thenable are adopted into a promise prevents the detection.
Having faced similar problems of trying to track the flow of eventual results, I'm confident thenable tricks isn't a solution.
I really didn't expect to see then getters (ab)used like that in the wild! I'm quite suspicious of how fragile this all actually is. This is effectively another form of Zalgo being released.
There is a long discussion on the topic at github.com/tc39/proposa.... Besides some of the performance concerns raised, my main concern is preventing the ability of some code to confuse other code it interacts with in the same realm. Adding an object to a collection should not have side effects.
'user" is a bit confusing here. If the hashCode / equal is a protocol implemented by the object, then the author of the object can affect all collections in which the object is added 👎. If the functions are per collection, then you lose the standard synchronization point 👎
An equality predicate is not sufficient for collections. Something like hashCode is also needed.
The problem with those is stability. There is no way to guarantee that user code will be side effect free and produce stable results.
Hey there, any update on the recordings of the presentations? Would love to reference it.
Next week TC39 will meet in Seattle to discuss new JavaScript language features 🎉
Please join us on Thursday 20th Feb at Docusign for a free @seattlejs.com community event featuring Linus Groh @ptomato.name @nicr.dev @ashley-c.bsky.social @lcas.dev @mhofman.bsky.social
lu.ma/s97y24jd
Mathieu speaking to a room of people about realms in JavaScript
Don't what a realm is in JavaScript? Ask @mhofman.bsky.social ! He is talking all about them :)
Really insightful read of @kriskowal.bsky.social's experience of helping bring modules to the JavaScript ecosystem.
And even though there was no actual vulnerability, we did pay out the researcher as it was a really informative report.
Got a similar report a few months ago. We were not actually vulnerable (CI is powerless on forks, and it couldn't affect any output), but it was a really good learning experience. Use env variables as much as possible in GH actions, those are sanitized.
Reminds me of an "RCE" last year where a JWT library was "vulnerable" to an object with a `toString` method. How do you think that method got there in the first place...
unit42.paloaltonetworks.com/jsonwebtoken...
my view is that large mission-critical systems that are targeted by threat actors are in fact multi-tenant systems (whether their authors realize it or not) and immutability is one of the tools for writing defensive code against potential threats running in the same process
Shoot, once again I'm away!
Yeah I'd say in general control flow based on API calls is a weakness in TS. Possible to implement yourself but very complex, and the standard library types don't do it.
Oh interesting. Wondering if this has something to do with integer index properties.
I was seeing similar scroll resetting weirdly on back navigation on Chrome on Android, but I haven't seen it today.
I have to admit, Twitter has a really good mobile web experience, even after the sabotages from Elon. The navigation in BlueSky mobile web is not great, and don't get me started on the lack of a manifest to support installing the web app and push notifications.
A flag which bans TS features with runtime emit (enums, namespaces, experimental decorators, etc) will come in 5.8 to help people executing TS code via Node.js (or who want to avoid using those features for "reasons").
Yeah it's been a known won't fix issue since 2020: github.com/microsoft/Ty...
Unfortunately TS is already not a superset of JS. Its syntax is ambiguous enough that some valid JS programs have different semantics when handled by a TS parser. Also not all TS programs can simply have their types stripped off.
GitHub can recognize and hide some generated files (e.g. from protobuf), not sure what the heuristics are. To enforce they are up to date, we just have a CI job that regenerates them and a check there are no dirty files (also good to handle lock files and similar)