UPI is great in terms of UX, but I don’t think it’s super reliable – especially big public banks go down all the time. The UPI base service had multiple incidents in the last 1 month too.
One would’ve thought that after looking at modern day computers that being able to run a wire through two computers being able to transfer data quickly, reliably, easily would be a 101 feature these boxes offer.
Back in the day, one could connect a bog-standard FireWire (IEEE 1394) cable betwixt a pair of Windows boxes, and it would create a (quite fast for the time) network for them to talk on.
Addressing was automatic with RFC 3927, and names just worked too.
After that, any appropriately-shared things on one machine would be accessible on the other.
OTOH corporate security gets paged whenever you plug something that isn’t a power supply or a monitor into the corporate box, up to and including an Ethernet cable.
I've seen banks disable USB ports by means of hot glue.
Hardware attacks are super hard to defend against. Depending on your threat model, drastic measures might be warranted. Anything with a USB plug can be a keyboard with an attack payload (e.g. Rubber Ducky). And if you think you can whitelist devices based on USB class or some identifier, you're wrong as they can be spoofed. Heck, there are "USB C cables" that are really attack payload delivery systems (e.g. O.MG Cable).
I created this because I found myself peeping inside type declaration files too often, and the only way to do that was by installing the package first.
tsdocs.dev helps you check the API surface of a good number of JS libraries and their past versions — usually a quick search away.
There's something powerful about speed and being able to answer questions in seconds that usually take minutes.
edit: The server might be overloaded with requests as we prime up our caches, but do visit back after HN's done hugging us to death.
You can show your support and help cover a part of server costs if this (or bundlephobia.com) saved you time.
This takes a big burden off of individual packages from publishing their own API docs (having done that I know how hard it can be!), and having a centralized API viewer can offer a lot of advantages over separate docs.
A couple of things I would suggest:
1. Track re-exports and cross-package references and allow crossref links to go into other packages. If package A uses rxjs, then links to the rxjs types should go to the canonical definitions in the rxjs package. (figuring out the canonical declaration can be tricky because it's not always the original declaration though)
2. Organizing by type isn't always a great introduction or way to navigate a package. On the Lit project at https://lit.dev/docs/api we re-organized the API docs by categories and the most important API surfaces. There aren't standard jsdocs for this, but a few straightforward things like @category could be used to offer an alternate top-level nav for a package. Also consider supporting the @packageDocumentation tag from tsdoc.
3. Consider showing files other than the README. Relative links to things like CONTRIBUTING.md currently break. Alternatively interpret all relative links as pointing to github.com or npmjs.com. It'd be great to have a way to link from the README into API docs to guide readers. The community doesn't have a great convention for this unfortunately.
> 1. Track re-exports and cross-package references
This should already be tracked — play around with the member visibility widget on the sidebar for e.g. For convenience, I've inlined the types from re-exports, but might be a good idea to indicate they were re-exported.
Pointing to the canonical source can also limit the usefulness in a few cases (e.g. d3 is just a bunch of re-exports), and users may not care about internal package organization.
> 2. consider supporting the @packageDocumentation tag
Organizing by @category and @packageDocumentation should already be supported. e.g. See the functions in —
https://tsdocs.dev/docs/lodash-es/4.17.21/index.html
Found a fun error "TypeDefinitionResolveError" for a package that includes Typescript sources. Best guess, it may be related to the package.json uses a modern "bare" exports field ("exports": "./index.js"; no "main", no "types") where "index.ts" exists in the package as well. (Not a lot of projects use this today, but it is a modern way to publish projects that will likely increase.)
Typescript itself works just fine with this with this type of package with "moduleResolution": "node" (tsconfig/CLI options) with recent version using recent enough ES targets or with "moduleResolution": "node16" in older versions/older ES targets/non-ES targets.
But we have an outdated system for general use, which is similar to what you have built: https://doc.deno.land/.
Did you know about this, and did you want to built your own system regardless, or did you not know about it and would this have been something you would have used instead of creating your own system?
Does this service do anything different/better than jsdocs.io?
I like the way jsdocs.io puts everything on one page.
I was initially confused when I looked up a package on tsdocs.dev and just got the readme. The actual type defs were tucked away out of sight in the hamburger menu. May just be a problem with the mobile site.
Hi, nice site! I found a small ux issue on ios: the search field has capitalization on by default. It can be turned off with https://stackoverflow.com/a/5171812
I attempted to build this a number of years ago but quickly got frustrated with the inconsistency of how packages are laid out and the unreliability of the information in package.json. Good job if you sorted it out though.
So I gave this a go for my canvas library[1]. The results are better than I expected, especially as (I assume) everything beyond the readme is being generated from my library's (handwritten) .d.ts file!
One question I do have: are there annotations and/or additional details that I could be adding to the file, or library, which could make the output more useful for anyone wanting to use this as a reference to the library? Also: how permanent is the output - is it going to regenerate every time someone hits that endpoint or is it robust enough for me to add a link to it from the library's website?
If I understand correctly, the limited amount of "expressiveness" a quantum computer has restricts its ability to solve useful problems.
Couldn't you simply express useful problems as a function of problems that the quantum computer can already solve? Doing so might be extremely in-efficient, but give that there's so much performance leeway, it still might end up being similar to super computers of today?
Question: Is Vite really a serious tool built for production apps? The design decisions don't give me confidence.
As your app starts to grow, you'd definitely not want 1000s of modules loading in your browser.
Seems like something that gets you from 0-60 quickly, and becomes a pain after.
Similarly, the different choice of bundlers in development and production would well lead to difference in behaviour / hard to catch bugs.
Shopify is using it with React. Lavarel now adopted it. It's the default for Vue projects going forward (given it's made by the person who made Vue).
Plenty of serious support behind it.
Not sure how you'd end up with "1000s of modules in your browser", unless you have some mega-project with an unwieldy package.json. I have a pretty complex Vue project app and it loads <100 .js files async and the vast majority are 100b and 95% will cache on the first load and never change. It's really not that big of a deal for modern browsers to load lots of tiny js files from your local machine in development.
I've found it to be way faster than Webpack for dev build times which is all that really matters to me.
Yes. Currently using it in production and couldn't be happier.
The individual modules are only served during development, but even then startup/load is faster than our previous webpack setup by an order of magnitude. When you build for production, you still end up with a bundle like you had previously.
It serves unbundled for development and bundled in production. In practice this works pretty well as long as you do decent code splitting (and you should be doing code splitting!)
Edit: lol I should have read your post more closely. Yes, the different strategies can cause bugs; there's much more shared between the two pipelines than there used to be so this situation is improving. We actually had really bad compatibility with problems six months ago and it was still easily worth the trouble for the performance improvement.
I really like the defaults Parcel comes with, it is very quick to get started with Parcel.
However, the promise of zero config is made possible in part by "magic" (strange conventions), and by having configuration spread across multiple files (package.json, . parcelrc, custom plugins which for some grave reason you can't use until you publish them to npm)
I really wish Parcel had sane configuration — I want to like it so much, but alas, it falls pray to the pendulum effect.
