What does HackerNews think of DefinitelyTyped?

The repository for high quality TypeScript type definitions.

Language: TypeScript

#20 in Hacktoberfest
#1 in TypeScript
#3 in TypeScript
> The sea of confusing types to solve any problem?

Mostly in typings either provided by the library itself or via the 3rd party DefinitelyTyped project. Some typings have been made so complex, that it is hard to follow what kind of concrete type is exactly expected or allowed.

[1]: https://github.com/DefinitelyTyped/DefinitelyTyped

> I'm thinking of building a text-annotation based app _alone in my spare time_. The core usage loop is about viewing and interacting with "visual markup" applied to a body of text. So lots of tooltips/hoverbars I guess.

Can you elaborate a bit more on this part, please? Or show us a mockup... doesn't have to be anything fancy, just like a pen and paper sketch or a simple Figma.

I'm asking because it kinda sounds like you're wanting to do something like an online IDE or Google Docs, where you're manipulating a body of text in the style of a rich text editor. If that's the case, it's possible the HTML DOM model isn't quite the right fit for you... you may find it better to abstract over a Canvas or WebGL object instead of trying to shoehorn that experience into the raw DOM. That way you have full control over rendering, outside of the normal layout/styling/rendering loop. It might also make a good case for a single-page app (at least the majority of the editor itself would be, and the other stuff -- marketing, blog, etc. -- can be routed to individual pages).

In that case, it wouldn't be so much a question of "framework" in the sense of React, Vue, etc., which traditionally work on the DOM. It might be more a question of "engine", like whether to use something like PixiJS to manipulate the graphics layer vs rolling your own. State management can be done with something like Redux (even without React), or if you choose to use a frontend framework for the rest of it, you can maybe use their state solution with your rendering engine.

In addition to choosing a low-level graphics lib, you can also look at some existing rich text markup solutions. A CMS I used had a good blog post on this: https://www.datocms.com/docs/structured-text/dast (especially the parts of about "abstract syntax trees"), along with their open-source editor: https://github.com/datocms/structured-text

That's one possible to way to deal with complex annotated text.

A more widespread one is the toast UI editor: https://ui.toast.com/tui-editor

I know you're not just working in Markdown, but these give you an idea of what it's like to work with complex text trees in JS.

Once you have the actual text editor part figured out, choosing the wrapper around it (again, just for marketing pages, etc.) is relatively trivial compared to the difficulty of your editor app. I really like Next.js myself (if you choose React), but I don't think you could really go wrong with any of the major choices today... React/Vue/Svelte/etc. And it looks to me like the complexity of your site wouldn't really be around that anyway, but the editor portion.

Lastly: I don't think ANY JS tool or package is going to be maintained in 10 years. Frankly, 2 years is a long time in the JS ecosystem :( I'm not defending this phenomenon, I hate it too, but that's the reality of it. If long-term maintenance is a goal of yours, you might want to consider writing abstraction layers over third-party tools you use, so you can easily swap them out when future things come out (because they will). The web itself is changing too fast for libraries to keep up; instead, people just write new ones every few years. An example of this is the pathway from the Canvas to WebGL to workers to WASM (and how to juggle heavy computational vs rendering loops around)... a lot of the old Canvas-based renderers, which were super powerful in their time, are now too slow vs the modern alternatives. Nobody is going to port the old stuff over, they just make new libs. It's likely that trend will continue in the JS world (that whatever you write today will be obsoleted by a new web API in a few years).

Lastly, as an aside, TypeScript is a superset of JS... if you find a JS project/lib/plugin that you want to use, there will often be types for it made by the community (https://github.com/DefinitelyTyped/DefinitelyTyped) , or you can write your own types for it. I don't really have an opinion about TypeScript vs writing in some other language and compiling to JS, but it would probably be easier to find help (especially frontend) in the future if you stick with TypeScript instead of convoluting your stack with multiple languages. Sounds like most of your app will be clientside anyway with limited backend needs.


Tech aside... have you considered partnering with a frontend dev for this? I know you said "alone", but just having someone set up the basic skeleton of such an app with you for the first month or two could be super helpful. Or a UX person to help you with some of the interactions before you start serious coding. They don't have to be with you the whole journey, but maybe they can help jumpstart your project so you can then work on adding features & polish in your spare time, instead of figuring out basic architecture? Unless, of course, that's the part you actually enjoy. In that case, don't let anyone rob of you that :)

Have fun! Sounds like a cool project.

Larger heavily contributed to repositories can be quite large, even if they are just plain code. Sure, not quite 5 GB large, but still.


  $ git clone https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
  $ du -h linux/.git
  2.8G    linux/.git

  $ git clone git://git.kernel.org/pub/scm/git/git.git
  $ du -h git/.git
  120M    git/.git

  $ git clone https://github.com/DefinitelyTyped/DefinitelyTyped
  $ du -h DefinitelyTyped/.git
  850M    DefinitelyTyped/.git

  $ git clone https://github.com/home-assistant/core
  $ du -h DefinitelyTyped/.git
  380M    core/.git

The above is also only taking into account repo size, while the GitLab limit applies to everything including release artifacts, CI build artifacts, hosted containers, etc. Many of which GitLab currently provides poor or sometimes even zero support for implementing purging.
Edit: Lol, I was looking at my previous submissions to HN and I noticed that I'd submitted[3] LavaMoat just a few weeks ago! Maybe with this recent Protestware stuff going on, that project can get a few more contributors wanting to help out.


Nice! Thanks for sharing that link. I've done a bit of digging into that project before and it's definitely a very promising idea.

It has a lot of the same pitfalls as Dyno, imo, in that it would require somebody to define a "security policy" for every module to whitelist permissions.

But, it's also something that could maybe be attached similarly to how TypeScript types are "retroactively" added for existing vanilla JS NPM packages. Ie, packages that have never added their own type declarations (like `express`) can have their types added to DefinitelyTyped[0] and published as a separate NPM package (`@types/express`).

It works fairly well and something like `@endo-policies/express` wouldn't be crazy to add in later. Obviously it's going to be super painful, but fixing tech debt is always going to hurt.

vm2[1] is another Node project with some semi-similar goals that's worth mentioning. It's not designed to be "applied" in the same way as Endo, but it does give you a way to "sandbox" dependencies.

As a security person, I am weary to trust something like vm2 because it is much harder to "get right" than a "sandboxed-by-default" approach like Endo or Dyno. Look at this[2] CVE on vm2 from a few months ago for some evidence about _why_ this approach isn't ideal.

I'm optimistic for the future but we still have a long way to go before we get to it!

0: https://github.com/DefinitelyTyped/DefinitelyTyped

1: https://www.npmjs.com/package/vm2

2: https://github.com/advisories/GHSA-6pw2-5hjv-9pf7

3: https://news.ycombinator.com/item?id=30280642

I suppose HPI[0] kind of is that? ;)

A community repository would be super nice for those. Something along the lines of DefinitelyTyped[1], all managed through git, easily integrates with other stuff (like shown on npmjs.org when the @types package exists), allows maintainers to "own" the adapters they contribute by making a PR. It's really the N adapters * T time per adapter that really makes it hard for one person to do. That plus monitoring API changes/flakiness of each adapter to make sure the data is still solid.

[0] https://github.com/karlicoss/HPI

[1] https://github.com/DefinitelyTyped/DefinitelyTyped

This is the use case that I'm familiar with. For packages that don't bundle types, type definitions are often available through DefinitelyTyped[0].

  npm install --save-dev @types/node
> The types should then be automatically included by the compiler

[0] https://github.com/DefinitelyTyped/DefinitelyTyped

i'm glad it worked for the author, and i am sure you can achieve better performance with Rust than with NodeJS, but i'd like to discuss some of the mentioned advantages:

in general, typescript is optimized for cooperating with other javascript code, to make it easy to drop it into a javascript-based project, and also, it does not really have it's own "runtime". typescript is javascript plus types. in fact, if you want to convert from typescript to javascript, you can take a typescript-file, and just delete all the type-definitions and you get a working javascript file (there are some exceptions to this, but it generally is true). this approach has it's downsides of course, for example,when you need to interface with a javascript (not typescript) module, you can easily, but you have to know what types it expects and returns,otherwise you might get invalid structures in your code. there are things that can help you there (https://github.com/DefinitelyTyped/DefinitelyTyped), and it works quite well in practice, but there is no 100% guarantee that the types will be correct.

>> STRICT TYPING (in typescript) For example, the data might contain additional fields or even incorrect values for declared types.

- typescript is structurally typed most of time, so if you have a function that needs an `{a:string, b:string}`, and you send it an `{a:string, b:string, c:string}`, it will accept it. it's a different trade off,sometimes better, sometimes worse, compared to nominal-typing (https://en.wikipedia.org/wiki/Nominal_type_system).

- the part "even incorrect values", it should not happen in your own code. as i wrote above, i can imagine it happening when interfacing with other non-typescript code.

>> DATA VALIDATION: You have to write data validation code to ensure that you’re operating on correct data in TypeScript. You get this for free in Rust...

in typescript if you want to read,let's say JSON data,and map it to a typescript-structure, and return an error if it does not have the correct structure, you can use libraries like IO-TS (https://github.com/gcanti/io-ts/blob/master/index.md) to make that happen. i do not know how you get this "for free" in Rust, i know there are libraries like Serde (https://serde.rs/) that do it.

PyCharm and JS (Babel) are only similar in that they turn text source code into AST's

With Python + PyCharm, the default mode is to allow developers to exclude and ignore types and code will still run, no matter how many orange/red markers are in PyCharms gutter. To change that mode, you need to consciously decide to add something to your workflow that will impede you if something is wrong e.g. git hooks to run linters, flake8, black etc.

With TypeScript, the default mode is to stop the developer in their tracks - the TS compiler will fail, and you can't run code (generated JS) that doesn't exist. Types are not optional, unless you make them explicitly so (which is still providing a type).

> I don't see how types can work if no type information is provided.

TS can still import native JS code... given that it has a TypeScript declaration file [0]. Many popular libraries offer one now, but many more do not. The community came together and created DefinitelyTyped [1], where 10k contributors have made 65k commits to provide TS declaration files for over 5,200 libraries spanning countless versions/releases.

This means a TS developer can import JS code that doesn't have 1st-party TS support, but does have 3rd-party through DefinitelyTyped.

[0] https://www.typescriptlang.org/docs/handbook/declaration-fil...

[1] https://github.com/DefinitelyTyped/DefinitelyTyped

GitHub is sending 500's on repositories and user profiles as well: https://github.com/DefinitelyTyped/DefinitelyTyped / https://github.com/TimWolla
One of the benefits to TypeScript is that the codebase wouldn't need to be rewritten.

A declaration file(s) could be included. There they could just declare types for all classes, methods, constants, etc. Similar to C header files.

(This is how the DefinitelyTyped repository handles typings for untyped source repositories: https://github.com/DefinitelyTyped/DefinitelyTyped)


JavaScript: app.js

    function app(arg1, arg2, arg3) {
       // does something
       return {
          key1: someStringValue,
          key2: someNumberValue,
TypeScript: app.d.ts

    declare type AppReturnValue = { key1: string, key2: number };
    declare function app(arg1: string, arg2: string[], arg3: boolean): AppReturnValue;
Almost as if Typescript is so complicated that getting your types "correct" is nearly impossible, especially when you add in the high variability in the quality of provided types on DefinitelyTyped [1].

[1] https://github.com/DefinitelyTyped/DefinitelyTyped

I have never used Flow beyond a basic hello world. The syntax is very similar. Some of the nomenclatures vary. All and all they will both accomplish 99% of the same thing - statically typing a dynamic language. Which gives you much more code confidence, `foobar is undefined` is very less likely. self-documenting code. (see: vs-code intellisense) And code maintenance scale abilities currently not possible with such a loose language like javascript.

So I would say if you're interested pick one and dive in.

Right now typescript has a lot of community momentum: https://github.com/DefinitelyTyped/DefinitelyTyped

And an extremely fast, open sourced, plugin enabled editor, vs-code ftw! I am a convert after being a longtime diehard vim user. (vs-code has the best vim binding emulation I have ever used in a free open sourced editor)

Facebook is deprecating their flow atom editor plugin; nuclide - https://twitter.com/fbopensource/status/1072928679695548416?...

This is all why I would choose typescript over flow if it were up to me. maybe a flow user can chime in.

> We wanted implementors of type systems for ruby to start collaborating, in particular on a repository of typed shims.

I see. Do you see this being a mono-repo of types that's under a Sorbet org or something Sorbet looks for in a gem if provided? Opening issues for a project's types with Typescript has been somewhat painful since many live in one repo [1].

1 - https://github.com/DefinitelyTyped/DefinitelyTyped

Can also confirm. Recently a convert and it's a breeze. It makes for more maintainable code, ultimately, and has even cleaned up some of my poorer JS habits.

Also, for those who get caught up rewriting types for existing libraries, I recommend you check this library first:


For anyone unfamiliar:

DT is "DefinitelyTyped", a github repo that consolidates type declaration files for open-source packages on npm.

Ironically, given the above comment, its tagline is:

> The repository for high quality TypeScript type definitions. (emphasis theirs)


I think the definitively typed [0] can be leveraged here for AOT compilation.

Looking forward to more details.


A VSCode person can (and probably will) answer in more detail, but at heart it's simple: if you want to add type-checking goodness to a library that isn't itself written in TypeScript, you can create a thing called a declaration file: https://github.com/DefinitelyTyped/DefinitelyTyped

Microsoft publishes a list of known good declaration files for popular npm packages to npm, under the scope @types: https://www.npmjs.com/~types

The 1.7 release of VSCode helpfully tries to automatically load type declarations for any npm package you use by requesting the equivalent declaration package under @types. When the package exists this is fine, because it's cached in our CDN.

What they forgot to consider is that most CDNs don't cache 404 responses, and since there are 350,000 packages and less than 5000 type declarations, the overwhelming majority of requests from VSCode to the registry were 404s. This hammered the hell out of our servers until we put caching in place for 404s under the @types scope.

We didn't start caching 404s for every package, and don't plan to, because that creates annoying race conditions for fresh publishes, which is why most CDNs don't cache 404s in the first place.

There are any number of ways to fix this, and we'll work with Microsoft to find the best one, but fundamentally you just need a more network-efficient way of finding out which type declarations exist. At the moment there are few enough that they could fetch a list of all of them and cache it (the public registry lacks a documented API for doing that right now, but we can certainly provide one).

If you're looking for Typescript type definitions for a project you're using check this list - https://github.com/DefinitelyTyped/DefinitelyTyped
Most popular projects have typescript bindings. Check out https://github.com/DefinitelyTyped/DefinitelyTyped for a big list.

If you're using a library and can't find bindings then I've found it's worth the time creating them yourself for any reasonably sized project. This is annoying and time consuming up front, but the benefits you get down-stream easily repay this initial investment.

I'm not sure how DefinitelyTyped works, but their repository https://github.com/DefinitelyTyped/DefinitelyTyped is huge and may be they use that github repository as a single distribution point.
Before Sameroom [1], we spent two years building Kato (https://kato.im), which became a Slack competitor once Slack launched. We did enjoy a brief pre-Slack honeymoon (at Techstars, no less).

For a few reasons, we chose Xamarin to build the Kato mobile apps. The end result was pretty good—great, even, considering the ridiculously tight timeline. We had a pretty elaborate common core with all the hard stuff (networking, caching, protocol, presence, etc), and custom UI code for Android and iOS.

In the end, since Kato was to be no more, the real benefit was seeing how much sense it makes to use a strongly-typed, object-oriented language for building complex user interfaces.

Many years ago, and for many years, we were C#/C++ programmers, so it wasn't exactly a revelation. But, we'd been working for quite some time with dynamically-typed Erlang and dynamically-typed Javascript (the Kato UI was built with Knockout.js).

Our server code was fairly straightforward and didn't change very much, so Erlang was an excellent choice there. With JavaScript, we'd programmed our way into some serious debt.

When deciding on a stack for Sameroom, we embarked on a quest to replicate the Xamarin experience for the web. We eventually narrowed in on Flux, React, and TypeScript.

After some experimentation, we got a development workflow working with gulp, shrinkwrap, make, and no particular IDE (we use Atom, Sublime, and Vim).

The biggest crutch was lack of JSX support in TypeScript, so splicing together HTML elements was pretty cumbersome. We viewed this as a temporarly incovenience, which was a good decision—TypeScript 1.6 got React/JSX in September 2015 [2].

We're pretty conservative about adding dependencies, but the overwhelming majority of libraries we do use have TS support available from the DefinitelyTyped project [3]. The few libraries that weren't supported (Stripe checkout and Intercom, if memory serves), we TypeScriptified ourselves.

As a result, working on the Sameroom UI is absolute joy.

It's a little ironic that, unlike Kato, Sameroom basically doesn't need a UI, since it's just marketing copy and an administrative dashboard.

[1] https://sameroom.io/blog/from-pivot-to-140-paying-customers-...

[2] http://blogs.msdn.com/b/typescript/archive/2015/09/16/announ...

[3] https://github.com/DefinitelyTyped/DefinitelyTyped

Yes. You just include a "type definition file" for Angular in your project. There is a very large existing repository of type definitions for popular JS libraries in the DefinitelyTyped project.


When I bang something up, I'll use Visual Studio 2015 and Typescript from the get-go, now that I'm used to it I find it much faster due to the Intellisense on all my code, and all the browser code too (and anything else I add typings for [1]).

I find it way, way, way more productive than plain old JS development without an IDE.

[1] https://github.com/DefinitelyTyped/DefinitelyTyped

EDIT: I always turn off optional any types, so everything has to be type annotated, even if that means I simply cast to an explicit . I find that non trivial problems in JS become so much easier in TS due to the compiler and built-in refactoring tools. I can't think of anything negative to say about TS at all!!!