Fix compatibility with bare runtime

[nampc1]

Description

I'm working on a swap module that uses @ston-fi/api. My goal is to make it run in Bare runtime. I have found a few problems and managed to fix them so that @ston-fi/api could work in bare. I tried my best to make sure my changes are not intrusive as well as not to introduce too many changes.

Changes

• The main problem is that @ston-fi/api uses camelcase-keys package that uses ES2018 regex, which bare does not support. Therefore, i replaced the package with another one that works just as well (humps) with no ES2018 regex. i ran all the tests and they all passed
• @ston-fi/api also uses ofetch package with its custom exports which leads to error in module mapping in bare (node-http not found), i resolved this by changing the build config of @ston-fi/api in tsup.config.ts
• in bare, seems like there's no origin attribute on URL object, so i added a fallback to href. this is in the constructor of StonApiClient

The swap protocol is now fully compatible with bare/node. We still need to wait for stonfi team to review my PR on @ston-fi/api

[pavel-rakhmanov]

Thank you for such a detailed contribution!

Here are my thoughts and estimation about the suggested changes:

• Package exports update: Absolutely valid, we can add it. I verified the build for attw with --profile node16, but it could easily be adjusted.
  We will do this as part of the next API SDK release.

• camelcase-keys replacement with humps: This looks easy, and also noticeably reduces build size (ESM build 39.75 > 25.5 KB). But because of the role of this dependency, we will first need to verify the same behaviour of the camelcase/decamelize functions with some real API responses.
  This will take a bit of time.

• Besides the fact that the bare URL interface's uniqueness is weird, the hassle we have to create a base URL is proven to be unnecessary and could simply be removed instead of using the href fallback.
  We can make these changes as part of the next API SDK release.

• Not sure about ofetch bundle as noExternal. Instead, it will probably replace ofetch with just fetch. From what I see, you can use bare-fetch in your runtime, and it will work for you.
  Need to validate this. This will take a bit of time

[pavel-rakhmanov]

Returning to this issue:

I was able to address a few action items in the previous release v0.25.0

• Package exports update
• baseURL href fallback

But the main one for you is still not addressed, unfortunately.
I wrote tests to find mismatches in the humps and camel-case function outputs and found that camelcase outputs are different in cases like "value_24h"

So the direct replacement without backwards-incompatible changes is unfortunately not possible.
This could be tweaked by using the regexp override in the optionsOrProcessor argument, but it would also require re-implementation of the CamelCasedPropertiesDeep type, which has the same difference in the output.

This, along with the upcoming release of a completely redesigned API (and SDK) v2, is planned for Q4 this year. This led me to the decision not to apply your current changes to the SDK, but to keep in mind these requirements to support other runtimes, rather than just Node.js.

[nampc1]

Hello @pavel-rakhmanov, thanks a lot for your effort testing this. I'm thinking about a less intrusive way to make this work in bare.

Basically, the problem is with the regex syntax that camel-case use, if we could replace it with a similar regex with older syntax, our problem will go away. so i think i can make a patch using patch-package to replace the regex that camel-case uses. that way, we would not need to replace the whole dependency camel-case, we just need to apply the patch. all of your test cases can still apply, you can quickly run all the tests to see if things work as before. do you think this is a more reasonable for you guys? @pavel-rakhmanov

Thanks in advance