51–60 of 239 posts
I'm curious as to why yarn instead of contributing to NPM? I am aware that yarn was the inspiration for many improvements for NPM by providing an alternative, but going forward do we need two systems? Is the plan for yarn to be compatible with NPM and package.json?
The move towards TypeScript 'winning' has been fast, and to everyone's benefit.
Earlier quoted context omitted.
Humans are not always the consumer of error output. Distinct error codes simplify parsing and eliminate ambiguity. It also makes it easier for developers look up a specific error in the documentation, assuming it's been documented.
How does an error code make it easier to look up an error? The workflow is either “get error, google it”, or “get errorcode google it”. In both cases the docs will be the top hit. If we where talking 20 years ago I might agree, but I really can’t see the argument with todays tooling.
Very happy to see yarn.lock will finally be a proper format that won't need its own parser. YAML subset is a pretty good choice, though I think canonicalized, indented JSON would be a better choice for this use case. Incidentally that's what npm uses as lockfile, I wonder if there's room to have the two package managers share the format (or even share the file itself). Very excited to see shell compatibility guarante…
> I think it's now clear that Facebook is admitting defeat with Flow. It sounds to me more like they're testing the waters. They're definitely opening up, with the whole Jest and create-react-app supporting it, but as far as using it themselves would this be the first project to be migrated?
Very happy to see yarn.lock will finally be a proper format that won't need its own parser. YAML subset is a pretty good choice, though I think canonicalized, indented JSON would be a better choice for this use case. Incidentally that's what npm uses as lockfile, I wonder if there's room to have the two package managers share the format (or even share the file itself). Very excited to see shell compatibility guarante…
> I think it's now clear that Facebook is admitting defeat with Flow. It sounds to me more like they're testing the waters. They're definitely opening up, with the whole Jest and create-react-app supporting it, but as far as using it themselves would this be the first project to be migrated?
And then there's... whatever this is:
https://twitter.com/jamiebuilds/status/1064649666275340288?l...
There appears to be a real movement to move from Flow to typescript. Is Flow dying?
I'm curious as to this trend as well. I've read the justifications for it in each case and in this particular one I don't get it. Isn't Flow more concerned with soundness than intellisense ? Has TypeScript caught up with Flow in this regard? Perhaps it's because I prefer to do my work in strongly typed, pure FP languages where I can but I work professionally with JS and have been investing in Flow there for over a ye…
I think the answer is: it's very close. It's still a little behind flow on soundness, but it's now close enough (if you enable strict mode, which you should!) that you're unlikely to notice the difference.
The TS type system is very impressive. It can't do everything that the functional languages can do, but it can do some things that they can't, and importantly it's still improving rapidly.
You may be interested in the roadmap/changelog page: https://github.com/Microsoft/TypeScript/wiki/Roadmap
Earlier quoted context omitted.
Humans are not always the consumer of error output. Distinct error codes simplify parsing and eliminate ambiguity. It also makes it easier for developers look up a specific error in the documentation, assuming it's been documented.
How does an error code make it easier to look up an error? The workflow is either “get error, google it”, or “get errorcode google it”. In both cases the docs will be the top hit. If we where talking 20 years ago I might agree, but I really can’t see the argument with todays tooling.
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?
Everytime I install a new package my previous `npm link` references break in the node_modules folder. `yarn link` keeps these reference. Just as I expect.
If package.json is already in JSON format, why not use the same for yarn.lock? Honest question, there must be a good reason.
Our lockfile format worked fine for the past three years (bar the unfortunate YAML incompatibilities that we're about to fix). Don't fix what isn't broken :)