pkg/yaml: YamlMap iteration order doesn't preserve yaml document order

[DartBot]

<img src="https://avatars.githubusercontent.com/u/444270?v=3" align="left" width="96" height="96"hspace="10"> Issue by seaneagan
Originally opened as dart-lang/sdk#21328

---

Here's the failing test:

import 'package:unittest/unittest.dart';
import 'package:yaml/yaml.dart';

main() {
  Map map = loadYaml(yaml);
  expect(map.keys.toList(), ['foo', 'bar', 'baz']);
}

var yaml = '''
foo: x
bar: y
baz: z
''';

Guessing it would just need to switch to an underlying LinkedHashMap so long as the keys are inserted in document order. I expected this to work given that it does with JSON.

[DartBot]

<img src="https://avatars.githubusercontent.com/u/444270?v=3" align="left" width="48" height="48"hspace="10"> Comment by seaneagan

---

YamlMap.nodes should preserve document order as well of course.

[DartBot]

<img src="https://avatars.githubusercontent.com/u/4865287?v=3" align="left" width="48" height="48"hspace="10"> Comment by lrhn

---

Added Pkg-Yaml, Area-Pkg, Triaged labels.

[DartBot]

<img src="https://avatars.githubusercontent.com/u/188?v=3" align="left" width="48" height="48"hspace="10"> Comment by nex3

---

The YAML spec actually explicitly forbids the native data structure to be based on the ordering of the keys in the document: http://yaml.org/spec/1.2/spec.html#id2763035

---

Added NotPlanned label.

[DartBot]

<img src="https://avatars.githubusercontent.com/u/444270?v=3" align="left" width="48" height="48"hspace="10"> Comment by seaneagan

---

Hmm, that seems over-specified, but the spec is the spec.

However, the native data structure is the YamlMap, YamlMap.nodes is just an AST attached to it. In fact, YamlMap.nodes already exposes the key order via the SourceSpans attached to the YamlNodes representing the keys and values:

var orderedKeys = yamlMap.nodes.keys.toList()..sort((a, b) => a.span.compareTo(b.span));

... it's just not very convenient. How about only preserving the order in YamlMap.nodes and not YamlMap? That would solve my use case, which is issue #4.