qs.parse doesn't handle encoded comma when parsing array with comma option

Hello this is my first time opening an issue here! First of all thank you for this amazing library.

Basically my company is following jsonapi’s spec for formatting filter in URL

GET /comments?filter[post]=1,2 HTTP/1.1

This works fine if the comma is not encoded

it('should parse post into an array', () => {
    expect(
      qs.parse('filter[post]=1,2', {
        comma: true,
      })
    ).toStrictEqual({ filter: { post: ['1', '2'] } })
  })

Atm our http library automatically encodes comma, which I suspect makes parse treat the comma-separated list as just a string.

it('should parse post into an array', () => {
    expect(
      qs.parse('filter[post]=1%2C2', {
        comma: true,
      })
    ).toStrictEqual({ filter: { post: ['1', '2'] } })
})

This test fails and the returned array is a string, "1,2".

Please let me know if there’s anything that I miss that would help.

P/S: After reading the source code and the tests I think maybe this feature is not supported.

t.test('arrayFormat: comma allows only comma-separated arrays', function (st) {
        st.deepEqual(qs.parse('a[]=b&a[]=c', { arrayFormat: 'comma' }), { a: ['b', 'c'] });
        st.deepEqual(qs.parse('a[0]=b&a[1]=c', { arrayFormat: 'comma' }), { a: ['b', 'c'] });
        st.deepEqual(qs.parse('a=b,c', { arrayFormat: 'comma' }), { a: 'b,c' });
        st.deepEqual(qs.parse('a=b&a=c', { arrayFormat: 'comma' }), { a: ['b', 'c'] });
        st.end();
    });

If you think this is not a bug but rather a missing feature, do you think it should be included in the lib?

[ljharb]

I’ve made a branch with 5 failing tests - 2 of which I don’t actually know how it would be possible to represent (nested arrays inside an object using the comma format).

A PR into that branch that improves the tests and/or provides a solution would be much appreciated.

[Ugzuzg]

I don’t think #237 is the solution to the problem above. I agree, that my comment is a duplicate of #387. I only commented in this issue, because it seemed relevant to me at the time.