Fix query-string bug in list.models() + introduce unit testing

[Adwaitbytes]

What's the issue?

While exploring the JavaScript SDK, I noticed that using both task and modelId filters together in list.models() produces malformed URLs:

// This currently produces: list/models?task=chat?modelId=gpt2
// Instead of: list/models?task=chat&modelId=gpt2
bytez.list.models({ task: "chat", modelId: "openai-community/gpt2" });

The string concatenation approach creates double question marks instead of properly joining parameters with &. This could lead to 400 errors or unexpected API responses that are confusing to debug.

What changed?

Fixed the bug:

• Extracted query-building logic into a dedicated utility function
• Used URLSearchParams for proper parameter joining and encoding
• Special characters (like / in model IDs) now get properly encoded

Added testing:

• Created the first unit tests for the JavaScript SDK
• Tests cover empty options, single params, multiple params, and special characters
• Run in under 1 second without needing an API key or HTTP mocking
• Added npm run test:unit for fast feedback during development

Improved contributor experience:

• Added CONTRIBUTING.md with dev setup instructions and testing guidelines
• Establishes a pattern for testing future SDK utilities

Why this approach?

I considered a few alternatives:

Approach	Trade-off
Fix the inline string logic	Still error-prone, hard to test
Add a query-building library	Overkill for this use case
Use URLSearchParams inline	Works, but testing would require mocking HTTP

Extracting to a pure function means we can test the logic directly without any network calls or complex mocking. The tests are fast and cover edge cases that would be easy to miss.

Testing

# Run unit tests (fast, no API key needed)
npm run test:unit

# All 4 tests pass in <1s
✔ returns base path when no options provided
✔ adds single query parameter correctly
✔ adds multiple query parameters with & separator
✔ URL-encodes special characters

Impact

• ✅ Filtered queries work correctly
• ✅ No breaking changes to the public API
• ✅ Establishes testing pattern for future SDK work
• ✅ Fast CI potential (unit tests don't need secrets)