I’m glad that Yarn will continue. Npm has improved, but it’s still less pleasant to work with than yarn (which basically always does what I expect, not so for npm).
Which part of npm acts unexpectedly?
Yarn's Future – v2 and beyond
11–20 of 239 posts
Re: Yarn's Future – v2 and beyond
#12There appears to be a real movement to move from Flow to typescript. Is Flow dying?
Does anyone know of any "third choice" around typing JavaScript? I would love to add types to my code, but I want to write "real" JavaScript: so the code I input is the code that is executed by the browser. I just want the compile step to strip away the type annotations.
There was initially talk of Flow using comments to actually work without touching the source code at all, but I don't think anything came of that... is there anything else on the horizon?
[Edit: Nevermind: I went looking for the github issue about adding types as comments, and it turns out it's already supported by flow: https://flow.org/en/docs/types/comments/ - is there anything like this for TypeScript?]
Re: Yarn's Future – v2 and beyond
#13There appears to be a real movement to move from Flow to typescript. Is Flow dying?
Both yarn and jest have announced they're switching to TypeScript. A corporate like Facebook would never allow that unless there was an internal shift in direction.
I'd consider flow dead.
Re: Yarn's Future – v2 and beyond
#14[deleted]
Re: Yarn's Future – v2 and beyond
#15There appears to be a real movement to move from Flow to typescript. Is Flow dying?
Flow really shines when you have a large, untyped codebase and want to incrementally add types to it. If you're starting a new project (or rewriting one) TypeScript is the more sensible choice. By nature Flow is going to be used less and less over time.
Re: Yarn's Future – v2 and beyond
#16> The log system will be overhauled - one thing in particular we'll take from Typescript are diagnostic error codes. Each error, warning, and sometimes notice will be given a unique code that will be documented - with explanations to help you understand how to unblock yourself.
Why do programmers love error codes? As an end user, they are useless indirection to me and the only way this would even be tolerable is if the explanation was printed directly next to the error code, so why bother? Is it code quality, since you don't have to write a long error message when you emit a similar error? But doesn't that have the drawback of encouraging error code reuse when it might not be appropriate?
[append]
Thanks for the replies! I guess I could understand error codes for search ability that also provide information about the problem specifics.
Counterexample:
$ yarn add foo
Error YARN1001: Incompatible peerDependencies.
$ yarn explain YARN1001
# Some longer text about how two of my modules have
# incompatible peerDependencies
$ yarn add foo
Error Yarn1001: Incompatible peerDependencies.
* my-package@1.0.0
|-* foo@1.0.0
|-* bar@1.0.0
|-* left-pad@1.0.1 (peerDependency of bar@1.0.0)
|-* left-pad@0.9.0 (peerDependency of foo@1.0.0)
$ yarn explain YARN1001
# Some longer text about how two of my modules have
# incompatible peerDependenciesRe: Yarn's Future – v2 and beyond
#17There appears to be a real movement to move from Flow to typescript. Is Flow dying?
Does anyone know of any "third choice" around typing JavaScript? I would love to add types to my code, but I want to write "real" JavaScript: so the code I input is the code that is executed by the browser. I just want the compile step to strip away the type annotations. There was initially talk of Flow using comments to actually work without touching the source code at all, but I don't think anything came of that...…
TypeScript works with JSDoc annotations: https://github.com/Microsoft/TypeScript/wiki/JsDoc-support-i...
Re: Yarn's Future – v2 and beyond
#18There appears to be a real movement to move from Flow to typescript. Is Flow dying?
Does anyone know of any "third choice" around typing JavaScript? I would love to add types to my code, but I want to write "real" JavaScript: so the code I input is the code that is executed by the browser. I just want the compile step to strip away the type annotations. There was initially talk of Flow using comments to actually work without touching the source code at all, but I don't think anything came of that...…
Yes, TypeScript can do type checking on regular Javascript (annotated with comments) as well: https://www.typescriptlang.org/docs/handbook/type-checking-j...
Re: Yarn's Future – v2 and beyond
#19Earlier quoted context omitted.
Does anyone know of any "third choice" around typing JavaScript? I would love to add types to my code, but I want to write "real" JavaScript: so the code I input is the code that is executed by the browser. I just want the compile step to strip away the type annotations. There was initially talk of Flow using comments to actually work without touching the source code at all, but I don't think anything came of that...…
TypeScript works with JSDoc annotations: https://github.com/Microsoft/TypeScript/wiki/JsDoc-support-i...
Can confirm, have sometimes added /* * @type Foo */ above a type and VS Code assumed that type was Foo everywhere else in my project, as if I typed `foo: Foo` directly. Didn't even have TypeScript in the project itself, purely an IDE feature. Extremely well thought out and useful ecosystem.
Re: Yarn's Future – v2 and beyond
#20The addition of vulnerability scanning was the only reason our company switched back to npm from yarn. Other than that, yarn offers a great experience