FYI: We can change the release cycle because we split the JS implementation from apache/arrow. We can release a new major version only when we need. We can release minor/patch versions when we need.

First of all, thanks for the crazy quick reply: first time that happens to me in an open source project!

I like that DuckDB allows me to access static datasets, however as domortiz stated, the moment I started working on my frontend I realized I had no typescript checking (just the good old tsc blindly using any type).

I have very little knowledge on the underlying library structure, but I'm pretty sure some refactoring will be required. I would start by proposing a change that shouldn't brake anything, and is super easy to implement: let the Schema constructor accept a typed dictionary like:

const schema = new Schema({
 'name': new AnonymousField(...args...),
 'age': new AnonymousField(...args...),
}, ...args...)

This would simply call new Field(key, ...args...) under the hood, just like my example.
This is simple and won't need much testing, but next part is better, if it gets properly tested (as it's a bit more complex).

Checking the Field class:

It looks to me we could get away with a simple dictionary with a {...args...} as const as IAnonField:

interface IAnonField<T> {
 name: string,
 type: T,
 nullable?: boolean,
 // This also is a bit sus, Why allow null *and* udnefined? Is it intended? Idk...
 metadata?: Map<string, string> | null
}
const x = { type: arrow.Int32 } as const satisfies IAnonField;
x.type; // this should show arrow.Int32 when hovering over it in vscodium

This means we let typescript know the field type, which is actually a value available at runtime in the javascript engine. I'll try working on this tomorrow instead, looks super promising 😄

Note: Javascript objects do not guarantee insertion order IF the key type differs (I see both strings and numbers are allowed in the same schema - like a field named 1 and one named "name")

Example of writer that uses both strings and numbers as keys (Symbols are not supported, so we don't even need to work with them):

// write.js
import { tableToIPC, Schema, Field, Uint8, Float32, Table, makeData, vectorFromArray } from 'apache-arrow';
import * as fs from 'fs';
const schema = new Schema([
 new Field('precipitations', new Float32()),
 new Field('0', new Uint8()),
]);
const table = new Table(schema, {
 age: makeData({ type: new Float32(), length: 3, data: vectorFromArray([1, 2, 3.14]) }),
 0: makeData({ type: new Uint8(), length: 3, data: vectorFromArray([7, 8, 9]) }),
});
fs.writeFileSync('simple.arrow', tableToIPC(table, 'file'));

And then, if we read we can see column order retention:

// read.js
import { tableFromIPC } from 'apache-arrow';
import * as fs from 'fs';
const table = tableFromIPC(fs.readFileSync('simple.arrow'));
console.log(table.schema.fields);
// Now you should see that the field '0' comes after 'precipitations', "not standard", but expected behavior IMHO

With that said, if we look into the friendlier makeTable & Co. the result is that objects are used from the get-go. So field order isn't crucial, from my understanding, however the underlying structure should probably respect it.

See PR #233