jiangmy

Did you mean something like an error stack?

That'll be significantly helpful if the last error is not apparent enough to solve the error. I'll investigate this and see if there's any performance impact on the inferring process.

Thanks for the bug reporting.

I have deployed a new version on the server to get this fixed!

Thank you all for sharing constructive thoughts and concerns.

I have written more FAQs on the website to make it more clear that what you can do with ESInfer. Plus, a `Comparison to Typescript` thread on the discussions repo on Github.

https://github.com/ESInfer/discus/discussions/1

And I'm planning to write more articles shortly.

  foo() + 1

ESInfer complains about this because you are adding a string with a number, which sometimes will result in an unexpected value in runtime, and you hardly find it out. So ESInfer, on purpose, disallows this kind of type casting automatically.

As for the error message:

> expecting possible candidates all failed: candidate number failed: expecting number but got string. candidate string failed: expecting string but got number. but got number.

It's saying two possible situations: #1 number + number and #2 string + string are all failed, which is precisely the error. However, this may be a lack of readability if someone is the first time using ESInfer. I'll write some wikis on how to read error messages efficiently as a starting point and, finally and hopefully, evolve a better error reporting system.

So if you ask me how to deal with this kind of code with ESInfer, I'd suggest making the compiler happy by converting the string to a number or the number to a string.

(BTW, try to use the format as suggested, hope it works :D)

Good One! There are two issues here:

1. Tuple or Array? The inferred type will be different depending on that decision.

Currently, I go for the Array one, so if you remove the `a[0].length` line, you will see `a` be inferred as `[string|number]`. But this will change if I think about this more thoroughly. What are your thoughts?

2. const/let constrain, constexpr, `if guarding,` and some internal methods are not implemented yet, so this is a false negative. But indeed will do!

Thank you for clarifying and providing the use case. It makes total sense to me! I'm adding this to my to-do list.

There can be many potential use cases, such as providing typing information to the IDE's LSP, ejecting them directly to the code as you suggested, integrating them into the CI process, etc.

I'm very open to providing all those possibilities, and there's no reason to limit how you use the typing information when you possess them automatically.

Hype up, Dude!

Very glad to see so many afford to make javascript a better language there! I played it around, and I found Hegel seems not to support dynamic features like modifications of objects or prototypes. And this is the real difficulty of implementing a sound and complete type system to a dynamic script language like javascript.

Can you share if they have any plans for that?

https://hegel.js.org/try#GYVwdgxgLglg9mABFApgZygCgIYEpEDeAUI...

https://hegel.js.org/try#MYewdgzgLgBCMF4YG8CGAuFAjTBGAvvgNwB...

Thank you for sharing that great work! It's more like a dependent-type plug-in to typescript to me, if I understand it correctly.

ESInfer and Ezno work on different layers, in my opinion. ESInfer provides a general ability to type-check code, yet Ezno improves a type system by adding the dependent type support. Ezno can work on top of typescript and could work with ESInfer, right? An easy way to do this is to use ESInfer to generate typescript annotations and then pass it to Ezno.

Yes, I did not do the paperwork well enough. I'm writing more articles and adding more examples on the website in the following days.

As a brief reply here, it provides the ability to do statical type inference for javascript without writing additional code. With this ability, libraries or editors can perform better on code assistant/suggestion, linting, statical analysis, annotation generation for or not for typescript/flow, and so on.

The difficulty comes from how dynamic language features you support & how accurate the type is inferred. Both in typescript and flow, you need to write annotations/comments to help the compiler perform well.

ESInfer is doing it all statically and without additional stuff needed. You can try it out on the playground section at the bottom of the homepage. Would be glad if there is any feedback :)

Thanks for your reply, and sorry for the confusion!

1. I replaced the GitHub link with a direct link now. Because it is still in the very early stage, the repo is only open for discussions like feature requests, using feedback, etc. 2. The main point is to do type check & annotation generation all automatically without one single line of additional code needed, which both flow nor typescript cannot achieve at present. 3. I'd like annotations to tip me on the type and to let the editor give me code suggestions based on them; however, I do not want to write them manually. 4. As for how to get type errors clear enough without learning, I'm doing it by avoiding using PL/type-system-related terms during the entire process. For example, `let a = 1; a = '1';` will raise an error that says `expecting number but got string.` to tell the user with easy to understand the sentence. For more complicated situations, like overloading mismatch, please experiment by the playground at the bottom of the homepage. (very sorry, I do not know how to write markdown on HN). Any feedback or thoughts on that is very welcome! 5. For the inferring result like `t547061|string` you pointed out. Yes, I agree that it's annoying. I will simplify the outcomes for the sake of readability over strictly correctness. But the top priority is still to add more ES6+ features if I think correctly.

Thank you again for the detailed feedback, and I apologize for any unclear caused. It's still early, and feedback like this is more than welcome. Thank you!