fix: Update body_size_limit to use Number instead of parseInt

[codenoid]

Summary
This pull request updates the environment variable handling in our SvelteKit application to support floating-point values for the BODY_SIZE_LIMIT. Previously, the BODY_SIZE_LIMIT was parsed using parseInt, which limited it to integer values. By switching to parseFloat, we can now define more precise limits, improving the flexibility of our application's configuration.

Changes
Changed the parsing method for BODY_SIZE_LIMIT from parseInt to parseFloat. This allows the use of both integers and floating-point numbers, providing more granular control over the body size limit.

Impact
Enhanced Flexibility: Users can now specify decimal values in the BODY_SIZE_LIMIT environment variable, enabling more precise control over request body size limits.

Backward Compatibility: Integer values are still supported. Existing configurations using integer values for BODY_SIZE_LIMIT will continue to work as expected.

BODY_SIZE_LIMIT=Infinity
BODY_SIZE_LIMIT=0x80000
BODY_SIZE_LIMIT=1e5

solve #11580

[changeset-bot]

🦋 Changeset detected

Latest commit: 892f318

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@sveltejs/adapter-node	Major

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[Rich-Harris]

Thank you — we also need to error if parseFloat(...) returns NaN instead of falling back to undefined, and we need a changeset

[Conduitry]

I think this should be a feat:, not a fix:. Unless @Rich-Harris you think we should play it safe and call it breaking: because people could conceivably be specifying values that parseInt to NaN?

[codenoid]

hi, could you please review my latest change, I'm not sure doing validation on top-level or somewhere

[Rich-Harris]

we should add a helpful error message in the case where people are currently using 0 to mean 'Infinity'. will do that now

[Rich-Harris]

@Conduitry I think we have to call it breaking because we're changing the meaning of 0 from 'Infinity' to 'zero'

[Rich-Harris]

thank you!

[codenoid]