Idea: leave type annotations as comments

[bmakuh]

I tried out Gear on a little tinkering project over the weekend (https://github.com/bmakuh/quip-mass-exporter/blob/master/index.js#L16) and I found myself continuing to comment out the type annotations so I could just run my script directly in Node rather than having to compile it first. What would you think about the possibility of having Gear parse type annotations in comments? That way it would continue to remain standards-compliant JS while gaining the ability to be type-checkable.

You could do something like require the line to start with triple slashes /// or something so that you wouldn't have to parse every comment, and you could limit it to only comments directly above a function definition or assignment.

[chriskrycho]

Even better: you could make it only parse comments which start //⚙️. :trollface:

More seriously, I'm definitely interested in this project and thought immediately of comments-as-types, because I've developed the habit of doing exactly that in my Node code already, like so:

// add :: number -> number -> number
const add = (a, b) => a + b;

//⚙️ add :: number -> number -> number
const add = (a, b) => a + b;

is probably not the best option, but something like it is a great idea.

[andywer]

Good point. I actually like to write those comments as well when not using gear (I don't use it for any critical code).

What I am concerned about: One could of course parse the comments, but I wouldn't want to do any strict type checking with this information, since it's still comments and comments should not be able to break the build.

But maybe I am thinking too conservatively here... 😅

My favorite compromise would be using decorators for the type annotations, but as long as node does not support them out of the box we would still need to transpile everything...

[andywer]

I am going to bed now and will give it some time to sink in. We can use this issue for further brain storming!

[bmakuh]

it's still comments and comments should not be able to break the build.

I guess that's true, although adding this comment to the top of a file can break a build: 😜

// @flow

[bmakuh]

But seriously though, the idea of being able to type-check existing JS codebases that have hindley-milner style comments would be amazing.

[andywer]

😅

After sleeping a night about it my biggest concern is defining complex types/shapes. I need to pass complex objects quite a lot:

// getUser :: string => User
function getUser (name) { ... }

I don't want to define those types in more comments... 🙃

Flow's type User = { ... } definitions seem to be the right way to go.

[bmakuh]

Yeah, I could see that. It would be fairly unpleasant to do this:

// type User = {
//   name: string,
//   age: number
// }
// getUser :: string => User
function getUser (name) {}

[andywer]

Another possible notation:

/**
 * In case you want to describe the function some more.
 * @type {string => User}
 * @see http://example.com/api/getUser
 */
function getUser (name) {}

But still does not solve the type User = { } issue...

[bmakuh]

@andywer I've thought a lot about how neat it would be to convert JSDoc annotations to Flow. Seems kind of like what you're getting at here, but you're right that it doesn't solve the ADT issue very cleanly.

[andywer]

This is interesting! https://twitter.com/thejameskyle/status/868148120504356864

Maybe this is the solution to all this and makes gear superfluous after all :)

[bmakuh]

This is interesting, too: https://github.com/origamitower/metamagical

[andywer]

It is. They just don't have type checking as it seems. Maybe if there was a babel plugin to transform their comments into flow type annotations or so... 🤔