Specify column order in table

Question

Specify column order in table

Closed this issue 6 years ago · 5 comments

AFAICT there's no way to specify the order of columns in tables. Am I missing something here?

Answer 1 · 2019-02-04T14:37:01.000Z

it's specified by the order of the keys

Answer 2 · 2019-02-04T19:42:25.000Z

Javascript Objects are unordered: https://stackoverflow.com/questions/5525795/does-javascript-guarantee-object-property-order.

Answer 3 · 2019-02-04T21:13:16.000Z

in node they are, which is why this works. Also in the post you linked it states that ES2015 made this the defined behavior as well.

Answer 4 · 2019-02-04T23:18:55.000Z

Node implements the spec for various versions of JavaScript, but it makes no guarantees beyond those specs. Therefore any other behavior falls outside the realm of the spec and is purely incidental; it could be changed at any time and without any warning.

The SO link above notes that ES2015 adds support for Map which behaves similarly to Object but maintains an ordering on the keys: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Map#Objects_and_maps_compared. The ES2015 spec does in fact define the ordering for Object keys here: https://www.ecma-international.org/ecma-262/6.0/#sec-ordinary-object-internal-methods-and-internal-slots-ownpropertykeys. But the library is still difficult to use in this configuration because

Relying on the ordering of keys in a JS Object is highly unconventional.
As a result, many linters require that the keys of Object literals be written in alphabetical order. Eg https://palantir.github.io/tslint/rules/object-literal-sort-keys/ and https://eslint.org/docs/rules/sort-keys.
The docs make no indication that ES2015 is required and that the library is not guaranteed to work for other JS versions.

Answer 5 · 2019-02-05T00:18:53.000Z

Look, I'm not going to engage in a theoretical debate. The behavior works perfectly as is and node isn't going to change this behavior so there is literally nothing to worry about.

If you can show me a code sample of something actually not working correctly then I'll revisit but there is no point in arguing about the spec. That is the case for node 8+ (at least) and those are the only versions oclif supports anyways.

Conventional or not, this is ergonomic and a clean way to design this functionality. I get that you don't agree, but this is the design we've settled on. If you use a linter that conflicts, just add an exclusion, or remove such a silly setting.