Wes Roberts

I agree with @SimonEast. This seems like something very easy to implement and would be much appreciated, especially now that we have `history --replay`.

I think the issue with this is the parsing strategy in general... 1. Get a list of key descriptors 2. Get a list of values 3. `merge()` them one-by-one For...

Okay I went ahead and implemented a `normalizeKeys()` solution, but I am realizing the problem stems even farther than I could have supposed. Apparently `qs.parse()` aims to support "semi-parsed" states...

The good news is my changes support object input, in case we want to keep it. My main question is... is there some non-obvious, important purpose of [Utils.compact()](https://github.com/ljharb/qs/commit/0f3c540320fe900c0f62fe4ad33eb28c940b8a02#diff-9f97a9c36fbbfb0d19068d6fae3bb84eR121) in qs.parse()?...

Okay, I can still fix the OP's bug, keeping the compacting and object input. But... why not add an `allowSparse` option while I'm at it? Maybe with a size limit?...

Just want to weigh in here that, for example, in PHP: ```php $x[]['id'] = 5; $x[]['id'] = 6; // produces: // [['id' => 5], ['id' => 6]] ``` I agree...

It works the same way.  I dug for some kind of spec or RFC that clarifies what to do here, but I don't think it exists. Edit: want to...

 ChatGPT suggested this feature as well lol

[TypeORM](https://typeorm.io/)

As a temporary workaround until this gets resolved: ```js module.exports = { settings: { 'import/ignore': ['react-native'], } } ```