> If you have a large enough codebase, you'll likely find a few cases where things work in TypeScript but its equivalent somehow fails type check in JSDoc.
You keep repeating this throughout the thread. Can you give an example?
Thanks for the example, I had a good play around with it.
The second part of my comment is a value yes, but it's implicitly typed by typescript automatically. I was asking about how to use that type (and it's internals) in jsdoc.
`test()` only returns a boolean, you want to look at `exec()` which returns the result of the regular expression (typed as: `RegExpExecArray | null` which you can narrow down to `RegExpExecArray` by checking if the result is null or not).
RegExpExecArray gives you a structure that looks different between the jsdoc version and the typescript version.
The typescript version has `.groups` inside RegExpExecArray.
You can use that as is, or you can add some extra type utilities to extract the named groups from inside the regex. (If you look inside typescript's issues on github you'll find a whole bunch of them that people have wanted typescript to include by default).
There's a few regex PRs to add extraction and syntax checking to typescript by default, but they're delayed until after the compiler switch from ts to go. (but there's porting to go in the PRs anyway).
Could you show me what you mean in the playground? You can change it to JSDoc mode by selecting "JavaScript" in the "Lang" dropdown in the "TS Config" tab.
Your examples has groups only typed as { [key: string]: string }.
It isn't narrowed down to the actual named capture groups inside the regex.
For the whole semver example, we'd want something typed as: { major: string, minor: string, patch: string }.
(sidenote for this semver example and not regex in general: they will be strings because a major of "01" and a patch of "3-prerelease" are both valid. You can parse them into ints later depending on what you're actually doing with the semver)
---
For an example of a type narrowed regex in the ts playground, I'll take the lazy route and point you to an example someone else has made:
You can use a utility library (e.g. ts-regexp, arkregex, etc...), you can use one of the utilities that are shared around the typescript spaces online for the one part you need, or you can make your own utility type.
---
For my use-case, I just want to know that I can change either my code or regex and I'll be alerted before runtime or buildtime if I've forgotten to account for something.
To carry on with the semver example, if a fourth piece of data was added to the incoming string (e.g. product name, build timestamp, build variant, etc...) and I forgot to update both the code and the regex together and instead only updated one, I'd want an alert in my IDE to tell me that I forgot to update the other one.
The behavior of ts-regexp is not especially related to the `RegExpExecArray` type. That package uses unsafe assertions to implement its API.
The only thing that requires TypeScript syntax in the playground you linked is the non-null assertions. Here's that same code in JSDoc mode with the non-null assertions removed (`strictNullChecks` is disabled instead): https://www.typescriptlang.org/play/?filetype=js#code/JYWwDg...
---
> For my use-case, I just want to know that I can change either my code or regex and I'll be alerted before runtime or buildtime if I've forgotten to account for something.
If you can show a concrete example what you want using TypeScript syntax then I'm pretty sure I could port it to JSDoc syntax. (To be clear I'd personally much rather write the TypeScript syntax as I find JSDoc comments annoying & verbose, but they're plenty powerful, being nearly isomorphic to TypeScript annotations.)
it is possible to do many of these with @typedef, but it gets difficult with JSDoc very quickly. In TypeScript you can easily create multi-line type aliases. Not quite so in JSDoc.
Sorry but this is a pointless survey. Not sure how one could determine whether RSS is alive when it already is.
The other problem is that the responses will be skewed depending on where you choose to advertise this survey and who's more passionate about taking it. Posting it here would likely trigger responses from those more inclined to say "rss is not dead", since that's what the overwhelming sentiment is here.
I can only conclude that you likely already know the survey is pointless, but it's being used to advertise for your RSS reader (you plug that in on multiple places on the site). You'd probably be better off just advertising your RSS reader instead.
The question is also meant somewhat ironically, i think everyone who uses rss knows that it is not dead.
But i still find it interesting to understand how people use rss and why they stopped.
Feeder did something similar, but stopped and I wanted to continue it.
https://feeder.co/blog/484-state-of-rss-survey-the-results
I also think that it would be wrong to not disclaim that I develop my own reader, but I am sorry that it looks like an ad, I will reduce this.
Don't know what you're so angry with Rachel about. I provide feeds for readers and many of them are way too greedy and frequently do hammer websites, often unneccessarily. Mix in all the rampant AI bots and you got a recipe for an extremely expensive server bill.
Getting angry at someone who's trying to keep their server costs down to provide you something for free is kind of weird.
- I've looked at the abyss of bankruptcy from server bills. I actually think it's a hell of a lot worse than Rachel does, I thought that 15 years ago, and I've suffered worse
- The whole discussion around RSS has been naive in every respect from the very beginning, for instance Dave Winer thinking we care about him publishing a list of the tunes he listens to back when you couldn't actually listen to them (I'll grant that in the age of Apple Music, Spotify, YouTube in such things may have caught up with him.) There are never any systems thinkers just people who see it all through a keyhole and can't imagine at all that anyone else sees it another way.
- To use a Star Wars analogy, Google is the evil empire that blew up up our planet with a Deathstar 10 years ago and now we're living on the wreckage in an asteroid belt. I see the AI upstarts as The Rebel Alliance that at the very least reset the enshittification cycle back to the beginning and create some badly needed competition. Opponents to A.I. crawlers are brainwashed/living in the matrix and defacto defending Google's monopoly and slamming the door to prevent the exits from enshittification that A.I. agents offer (e.g. they look at the content and drop out the ads!) They think they're the rebel alliance but are really the stormtroopers suppressing the resistance until the Deathstar charges up for the next shot.
- Rachel's supposedly some high powered systems programmer or sysadmin or something but is just as naive as Winer. We're supposed to "just" use a cache. Funny, the reason why the web won out of every other communication protocol is that you can "just" use curl. curl by it's nature can't support cacheing because it's a simple program that just runs in one process and if you wanted to have a cache you'd have to have a complex locked data structure which would force a bunch of trade offs... like I am downloading something over my slow ADSL connection that takes two hours but I also need to clear my cache so do I force the download to abort or hang up the script that needs the cache cleared for two hours? curl is "cheap and cheerful" because you just don't have to deal with all the wacky problems for which "clear the cache" or "disable the cache" clears up like a can of Ubik. But in the age of "Vibe Coding" solutions that almost work are all the rage, except when you finally realize they didn't actually work you clear your cache and rerun and BAM you got banned by Rachel's blog because you hit it twice in 24 hours.
Web browsers are some of the most complicated software in existence, ahead of compilers (they contain compilers) and system runtimes (they are a system runtime), right up there with operating systems (less having to know things that aren't in the datasheet to write device drivers at least.) For the first 15 years you could not trust the cache if you were writing web applications, somewhere around 2010's I finally realized you could take it for granted the cache works right. I guess implementations and the standards improved over time but all this complexity is some of the reason why it is just Google's world and we all live in it and there are just two big techs that can make a browser engine and one unaccountable and out-of-touch foundation.
So I wish Rachel would just find an answer to the cost problems (Cloudflare R2?) or give up on publishing RSS or advocate activitypub rather than assume we care what she says enough to follow her rules for her blog without seriously confronting what a system-wide solution for the problems RSS tries to solve and the problems it poses.
Nice. How are you syncing and deduping the data? The page says it uses an API but doesn't go into detail of which. Is there storage and caching implemented?
Then I host everything on a firebase service where I store all data and serve it up quickly.
There are some small problems with de-duping when a podcast gets uploaded on multiple feeds, but I haven't found a great way to handle that besides comparing the titles/descriptions
Well that sucks. Fortunately, there are apps that still allow you to generate RSS feeds like rss.app. OpenRSS.org may also be of interest, an organization built to fight against companies that get rid of their RSS feeds.
You keep repeating this throughout the thread. Can you give an example?
reply