5 ms·

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, i

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 guarantee in scripts as well. Using environment variables in scripts is a pain right now. Finally one of the biggest news is the switch from Flow to Typescript. I think it's now clear that Facebook is admitting defeat with Flow; it brought a lot of good in the scene but Typescript is a lot more popular and gets overall much better support. Uniting the JS ecosystem around Typescript will be such a big deal.

aylmao 8y ago
> 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?
- basil-rash 8y ago
  Jest is migrating to typescript: https://github.com/facebook/jest/pull/7554#issuecomment-454358729 https://github.com/facebook/jest/pull/7554#issuecomment-4543...
  - aylmao 8y ago
    Oh, gotcha! Missed that comment.
- scrollaway 8y ago
  Jest is getting migrated to Typescript as well, not just adding support for it. And then there's... whatever this is: https://twitter.com/jamiebuilds/status/1064649666275340288?lang=en https://twitter.com/jamiebuilds/status/1064649666275340288?l...
  - ggregoire 8y ago
    He’s right. I’ve been using Flow for 2 or 3 years, the tool does the job but it has many bugs and NO support AT ALL. Same for the communication, no roadmap, no yearly post about what’s going on, nothing. I started moving our projects to TS too.
  - Klathmon 8y ago
    >And then there's... whatever this is: I respect Jamie for the things done and built, but his views tend to be a bit extreme. I agree that flow is not in a good place right now, but to say that they don't give a shit about the community just isn't true. Flow has been making significant strides in community outreach, inclusion, and detailing their roadmap lately. And Facebook dropping flow would bring us toward a monoculture which I personally think is a bad thing (it's always good to have some competition to keep new ideas flowing and stuff improving), and Jamie advocating for it seems misguided and shortsighted. Flow happily accepts contributions from outside people, but because of the somewhat esoteric language choice (ocaml) and the fact that it's significantly smaller in terms of community usage means that there isn't that many people to contribute anyway.
    - coldtea 8y ago
      >I respect Jamie for the things done and built, but his views tend to be a bit extreme. They might be in general, but these sound like some easily objectively checkable claims: "If you want visible proof of this [Flow not caring for the community], just look through the repo. PRs are never merged. Issues are never addressed. Pretty much all of the activity there is done by a couple people in the community. Critical issues stay open for years. They do all of their development internally"
      - Klathmon 8y ago
        PRs are never merged because the github repo isn't the source of truth for Flow, their internal systems are. They have this workflow where they will import PRs from github and apply them internally, then close the PR when it's done. At a glance, it looks like all PRs are just closed, but looking at them individually shows a different story. It's the same with React-Native, and several other OSS projects by facebook, and Jamie knows that, having worked at FB when that workflow was used. It has its faults (I personally really hate the workflow they use, but I get why they use it. Github is where the people are, and Phabricator and other internal tools are difficult to integrate into it in a lot of cases, but I still hate it), but to say it's because they don't care about OSS or they do all their work internally isn't true. Plenty of FB employees and outside contributors both make PRs on github, discuss them on github, and just merge them internally closing the PR on github. Flow has plenty of issues without needing to make them up or exaggerate them. Their errors still take weeks for many to understand and get used to, flowtyped is a mess compared to typescript's type distribution system, their fucking habit of single character type variables makes looking at built in type definitions extremely difficult, the flow binary still is extremely unstable on windows even after years, and the recent move of aliasing Object and Function to `any` seems like a misguided attempt to simplify some code and speed up some checking. But at no point do I think they should can the whole thing, and I absolutely think they care about open source. Like I said in the comment above, Flow is in a bad place right now, but they are putting their money where their mouth is, the Flow team is reportedly growing at FB, and over the past few months I've seen a massive uptick in the number of releases, blog posts, external contributions, performance, and a significant decrease in the number of bugs I was hitting on a daily basis.
wopian 8y ago
npm's lockfile is a pain to diff in PRs because of the JSON format where what was maybe 20 changed lines in yarn is upwards of 80 from the brackets. With YAML and whatever format yarn.lock was in, the only changed lines are changes to the version resolutions, hash and dependencies.
- donatj 8y ago
  I'd say safely merging YAML diffs however could be trouble. I don't know how restricted their YAML subset is, but in my experience it's so loose a format the only way to be sure YAML says what you think it says is to run it through a parser.
  - drodgers 8y ago
    > safely merging YAML diffs however could be trouble Yarn will actually do the merging automatically — if you have conflict markers in your lockfile, just running yarn will parse them along with the rest of the file and produce a new lockfile with the changes from both diffs (unless there's a genuine conflict). I assume that this feature won't go away with the new lockfile format
    - Vinnl 8y ago
      I hope so, but that feature wasn't there from the start: https://github.com/yarnpkg/yarn/pull/3544 https://github.com/yarnpkg/yarn/pull/3544 Hopefully they'll be able to re-use much of that work for the Yaml file.
  - DuskStar 8y ago
    I think if you're merging lockfile diffs, you're doing something wrong! Merge the package.json diffs and regenerate the lockfile.
    - tlrobinson 8y ago
      Yarn automatically resolves conflicts in yarn.lock if you run "yarn": https://github.com/yarnpkg/yarn/pull/3544 https://github.com/yarnpkg/yarn/pull/3544
cphoover 8y ago
Nah YAML is better because of diffing. JSON uses commas `,` which will show multiple changes when the last item of a list changes.
- int_19h 8y ago
  Side note: it's really sad that more languages aren't allowing trailing commas in sequence literals and other places, like Python does. In Python, these are legal: [1, 2, 3,] foo(1, 2, 3,) And thus, when writing multiline literals and calls, it's pretty common to use the comma as a line terminator, precisely so that new lines can be added at the end without touching the previous line.
  - ergothus 8y ago
    Javascript DOES allow trailing commas, though it never caught on since IE6 would blow up on them. JSON, however, does not.

aylmao 8y ago

> 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?

basil-rash 8y ago
Jest is migrating to typescript: https://github.com/facebook/jest/pull/7554#issuecomment-454358729 https://github.com/facebook/jest/pull/7554#issuecomment-4543...
- aylmao 8y ago
  Oh, gotcha! Missed that comment.
scrollaway 8y ago
Jest is getting migrated to Typescript as well, not just adding support for it. And then there's... whatever this is: https://twitter.com/jamiebuilds/status/1064649666275340288?lang=en https://twitter.com/jamiebuilds/status/1064649666275340288?l...
- ggregoire 8y ago
  He’s right. I’ve been using Flow for 2 or 3 years, the tool does the job but it has many bugs and NO support AT ALL. Same for the communication, no roadmap, no yearly post about what’s going on, nothing. I started moving our projects to TS too.
- Klathmon 8y ago
  >And then there's... whatever this is: I respect Jamie for the things done and built, but his views tend to be a bit extreme. I agree that flow is not in a good place right now, but to say that they don't give a shit about the community just isn't true. Flow has been making significant strides in community outreach, inclusion, and detailing their roadmap lately. And Facebook dropping flow would bring us toward a monoculture which I personally think is a bad thing (it's always good to have some competition to keep new ideas flowing and stuff improving), and Jamie advocating for it seems misguided and shortsighted. Flow happily accepts contributions from outside people, but because of the somewhat esoteric language choice (ocaml) and the fact that it's significantly smaller in terms of community usage means that there isn't that many people to contribute anyway.
  - coldtea 8y ago
    >I respect Jamie for the things done and built, but his views tend to be a bit extreme. They might be in general, but these sound like some easily objectively checkable claims: "If you want visible proof of this [Flow not caring for the community], just look through the repo. PRs are never merged. Issues are never addressed. Pretty much all of the activity there is done by a couple people in the community. Critical issues stay open for years. They do all of their development internally"
    - Klathmon 8y ago
      PRs are never merged because the github repo isn't the source of truth for Flow, their internal systems are. They have this workflow where they will import PRs from github and apply them internally, then close the PR when it's done. At a glance, it looks like all PRs are just closed, but looking at them individually shows a different story. It's the same with React-Native, and several other OSS projects by facebook, and Jamie knows that, having worked at FB when that workflow was used. It has its faults (I personally really hate the workflow they use, but I get why they use it. Github is where the people are, and Phabricator and other internal tools are difficult to integrate into it in a lot of cases, but I still hate it), but to say it's because they don't care about OSS or they do all their work internally isn't true. Plenty of FB employees and outside contributors both make PRs on github, discuss them on github, and just merge them internally closing the PR on github. Flow has plenty of issues without needing to make them up or exaggerate them. Their errors still take weeks for many to understand and get used to, flowtyped is a mess compared to typescript's type distribution system, their fucking habit of single character type variables makes looking at built in type definitions extremely difficult, the flow binary still is extremely unstable on windows even after years, and the recent move of aliasing Object and Function to `any` seems like a misguided attempt to simplify some code and speed up some checking. But at no point do I think they should can the whole thing, and I absolutely think they care about open source. Like I said in the comment above, Flow is in a bad place right now, but they are putting their money where their mouth is, the Flow team is reportedly growing at FB, and over the past few months I've seen a massive uptick in the number of releases, blog posts, external contributions, performance, and a significant decrease in the number of bugs I was hitting on a daily basis.

wopian 8y ago

npm's lockfile is a pain to diff in PRs because of the JSON format where what was maybe 20 changed lines in yarn is upwards of 80 from the brackets. With YAML and whatever format yarn.lock was in, the only changed lines are changes to the version resolutions, hash and dependencies.

donatj 8y ago
I'd say safely merging YAML diffs however could be trouble. I don't know how restricted their YAML subset is, but in my experience it's so loose a format the only way to be sure YAML says what you think it says is to run it through a parser.
- drodgers 8y ago
  > safely merging YAML diffs however could be trouble Yarn will actually do the merging automatically — if you have conflict markers in your lockfile, just running yarn will parse them along with the rest of the file and produce a new lockfile with the changes from both diffs (unless there's a genuine conflict). I assume that this feature won't go away with the new lockfile format
  - Vinnl 8y ago
    I hope so, but that feature wasn't there from the start: https://github.com/yarnpkg/yarn/pull/3544 https://github.com/yarnpkg/yarn/pull/3544 Hopefully they'll be able to re-use much of that work for the Yaml file.
- DuskStar 8y ago
  I think if you're merging lockfile diffs, you're doing something wrong! Merge the package.json diffs and regenerate the lockfile.
  - tlrobinson 8y ago
    Yarn automatically resolves conflicts in yarn.lock if you run "yarn": https://github.com/yarnpkg/yarn/pull/3544 https://github.com/yarnpkg/yarn/pull/3544

cphoover 8y ago

Nah YAML is better because of diffing. JSON uses commas `,` which will show multiple changes when the last item of a list changes.

int_19h 8y ago
Side note: it's really sad that more languages aren't allowing trailing commas in sequence literals and other places, like Python does. In Python, these are legal: [1, 2, 3,] foo(1, 2, 3,) And thus, when writing multiline literals and calls, it's pretty common to use the comma as a line terminator, precisely so that new lines can be added at the end without touching the previous line.
- ergothus 8y ago
  Javascript DOES allow trailing commas, though it never caught on since IE6 would blow up on them. JSON, however, does not.