Query string handling with fastify different than express?

[neon orbit]

How can i make the querystring with fastify work the same as express. I was trying to use this addition to nodejs for paging and filtering queries with mikro-orm https://github.com/emulienfou/nestjs-mikro-orm-pageable and it wasn't working correctly for filtering. I checked out the code and switched out the e2e tests to use fasitfy and all the filtering tests failed. You can see one here: https://github.com/emulienfou/nestjs-mikro-orm-pageable/blob/3277e1dfac53d431181b1f799835669ca064d408/e2e/e2e-spec.ts#L74

I then checked the code and noticed that this hasParam check succeeds in express, but not in fastify. https://github.com/emulienfou/nestjs-mikro-orm-pageable/blob/main/src/decorators/paginate.decorator.ts#L85

How can i make it behave like express does in this regard?

[neon orbit]

I should also mention the output i see with express when dumping the query from the first filter test which is:
query { filter: { id: '4' } }
and on fastify it is:
it is query Empty <[Object: null prototype] {}> { 'filter[id]': '4' }

[neon orbit]

Ah, if i use a plugin like https://www.npmjs.com/package/fastify-qs which forces qs, the tests pass

I'm suprised that the fastify platform package doesn't use qs to match the express behavior

[brave wolf]

I guess that's because fastify users want to controll this behavior themselves. But yeah, this is odd if you're migrating from expressjs to fastify

[neon orbit]

I thought the point of the platform packages was to offer consistent behavior

with the ability to drill down to specifics if you need it

[brave wolf]

I agree

[neon orbit]

this little module actually has fastify checks in it, but doesn't actually run the test suite against fastify so i didn't realize it wasn't going to work properly

[brave wolf]

at same time, I guess kamil designed it in a way that @nestjs/platform-fastify shouldn't be depending on fastify packages that are not under @fastify/ scope

[neon orbit]

or it could just be an oversight. I guess I should file a bug to get the specifics

There's nothing in the query string spec that suggests how arrays or objects should be handled and if you're just doing normal stuff there's no problems

[neon orbit]

Hmm, but could this be considered a bug? the bug reporting page suggests asking here first