When a route's parent's allowList is a function and the child's isn't, the app will crash because the code makes a weird check to see if the parent's parameter is a function and if so, calls params.allowList as a function (!), the params config's allowList can also be an array of IPs though (coming from the config object) and crash the app upon invocation
The rateLimit decorator also ignores the configuration when the timeWindow property isn't set. However, there might be times where we only want to change the max, or some other parameter
Now, the decorator and the config property behave exactly the same
The reason for moving objects out of the main function is that, as this plugin supports being registered multiple times with multiple stores, we risk recreating these objects every single time
And finally, I tried to minimize the amount of intermediate objects that are created
Here's what it fixes concretely:
allowListis a function and the child's isn't, the app will crash because the code makes a weird check to see if the parent's parameter is a function and if so, callsparams.allowListas a function (!), the params config'sallowListcan also be an array of IPs though (coming from the config object) and crash the app upon invocationhttps://github.com/fastify/fastify-rate-limit/blob/18df4d3a33d32bf9c71f2d842117140e7e3b4bfc/index.js#L190-L198
timeWindowproperty isn't set. However, there might be times where we only want to change the max, or some other parameterhttps://github.com/fastify/fastify-rate-limit/blob/18df4d3a33d32bf9c71f2d842117140e7e3b4bfc/index.js#L118-L123
Now, the decorator and the
configproperty behave exactly the sameThe reason for moving objects out of the main function is that, as this plugin supports being registered multiple times with multiple stores, we risk recreating these objects every single time
And finally, I tried to minimize the amount of intermediate objects that are created