Yeah, all of mine were similar. Weird 11th hour bugs that took me a while to figure out.
Also as so many of my projects are web apps, I'm usually using solid or svelte, and then I need a package.json and a deno.json, which feels like it defeats the purpose.
Minor thing, but lots of paper cuts.
Ah, yeah I see now. Bummer :(
Oh maybe I misread. Are you asking for people who used to use deno but have left it? Because if so I can give my 2c (as someone who really loves deno but has consistently struggled to make it work in projects, which might just be a me thing).
Did something happen at Deno?
Vite+ is open source under MIT and free for everyone.
Holy shit I had a similar experience a few months ago, also with a medical provider! Horrible.
Nothing tops (yet) when I had to talk to a chatbot to get it to render me the unsubscribe button for a particular service. They removed their unsubscribe page 🫠
Is this a different feature than using the Github Copilot Chat LLM provider? I've been doing that for a while already and am confused if/how this is different.
Screenshot of a comparison table showing vue, svelte, and solid-js, three npm packages, with side-by-side facets: downloads/wk, package size, install size, module format, typescript status, engines, vulns, last updated, license, and num of dependencies
I'm working on adding this to a certain stealthy OSS npm package browser.
Would you use this? What's missing?
wow yeah 90% of what I was doing working on this was fixing edge cases (and there appear to still be more)
not sure i'm happy or sad that i missed this earlier haha (it was fun reading the doc AST! but yeah wow...)
will play with this later and see if i can massage it back into looking similar!
thank you all for all your work on deno_doc!
I didn't see `generateHTMLasJSON` but that might be easier than what I'm doing if it does what it sounds like.
though we're preprocessing the shiki highlighting server side here too, so maybe the raw doc nodes are more flexible for this use case
skipping over the details a bit, and there are still some rough edges (especially for complex packages with sprawling entrypoint graphs)
but works surprisingly well!
pretty naively in this first pass!
i'm basically:
1. fetching type urls from esh.sh with an `x-typescript-types` header
2. run it `@deno/doc` slightly patched to get WASM to work on a vercel function
3. take the `DenoDocNode[]` structured AST result
4. flatten, transform, merge, render to HTML
(sorry lol)
just took a quick peek and nothing stands out but i'll pull it up in more depth tomorrow!
Thank you!!
Lots of fun directions we can take this, and I'm sure I missed some edge cases. Real heavy lifting here and shoutout goes to the @deno.land folks for providing the underlying tooling.
All I did was a little glue code really.
js doc `@examples` were working for other packages that I was checking, but likely I missed something!
tons of edge cases here--mind if I poke around later?
one fun thing i learned from this little deep dive into `deno docs`' output is that it gets a ton of info that I wouldn't have expected
so might be other things exposed here that we didn't expect to show up!
🔥 amazing PR just merged from @wlls.dev using @deno.land's docs package to generate docs for any package on the npm registry ....
Your project deserves docs.
$ npx skills add nuxt-content/docus
Then: "/create-docs"
Full doc site with SEO, MCP, copy page, llms.txt, everything automatic.
Your AI can now read your docs. Your users can search it. Google can index it.
In less than 2 minutes, give it a try👇
a screenshot from the #contributing channel in a new project discord server. patak says: @Emanuele you can choose by the way, commenting is good, and start doing an issue directly also works. If two people work on the same issue at the same time, for OSS is actually a good thing. It is different than when you are working on a company and would like to maximize output. Here, if you start implementing something, and someone beats you to it and sends a PR, the knowledge you gained while trying is very valuable. You can help review the PR and make the implementation better in that way. Maintainers can even add you as co-author. And both of you will then have more experience on that part of the codebase, that is great for later. you can also think that there are now 30+ devs checking and working on the repo so if you want to coordinate that in a fine-grained way, you introduce a lot of bottlenecks it is more efficient to just let everyone do what they feel is more important and help each other when they collapse and you'll be surprised by how little collapse ends up happening, because there is a lot of side comms here too that arranges things naturally
when you collaborate in open source teams, you need to unlearn a lot of what your company work taught you
a package information dashboard showing a range of stats for eslint-formatter-gitlab, including a star count and number of forks
so we just added support for @tangled.org in our npmjs ui.
plus:
- bitbucket
- @gitlab.com
- gitee
- @gitea.com
- codeberg
- sourcehut
which others am I missing?
I'm asking because I'm building an alternative to npmjs.com, including the admin ui piece
I have a working mvp, although of course it's very 🚧
if this is something you'd like to contribute to, and you've experienced any of these pain points, let me know - always more fun to build together! 🙏
This is all in response to whether one should publish to JSR or not based on its adoption. From a usability perspective, you aren't blocked from using JSR alongside node/npm.
The bigger question in my mind is whether JSR survives if it never gets more adoption, but that's hard to say.
If a package was only published on jsr, you can install it via the methods described in that compat doc.
It doesn't matter whether you're using deno or node-based package managers (pnpm, yarn, etc) or bun, you can install from either registry (minus the caveats described there).
I'm not understanding your question, sorry! What are you trying to do?
My point is that you can install npm and jsr packages regardless of package manager / where they're published.
So if effect sql is only published on npm, you can install it via npm.
Ah, I see!
I guess there's no harm in that then. Still wish either JSR was more widely adopted or Microsoft would invest more in improving npm / npmjs.com.
But if neither of those is going to happen it would be preferable to not get flashbanged when I open npmjs in the middle of the night.
Confused by this. You can install packages from jsr and npm currently, e.g.
pnpm install jsr:@luca/cases
or
npx jsr add @luca/cases
That is to say you can easily install from npm or jsr regardless of whether you're using deno or not.
There are some limitations, but largely minor.
Is there something specific JSR doesn't improve over the existing `npmjs.com` that your alternative would? Would it be more effective to contribute that to JSR directly and collaborate there?
