Closed balazsbotond closed 1 year ago
If this were me, I would do a mix of options 1 & 2. qs isn't a terribly complicated library, forking it or even just vendoring it into urlcat seems like something reasonable both in terms of effort and maintenance. Then, for option 1, it should be possible to refactor the existing code to use ES Modules, which is supported by Node (albeit in behind the experimental flag).
Imo ES Modules is probably the best way to remain cross-platform compatible in the long run; browsers alrady support it, so does Deno (with the caveat that imports must specify the file extension) and it would be very surprising if Node decided to drop support for it.
As for tests, I wouldn't worry too much about it; just pick a platform for development and choose a tool that work on that platform, the important thing is to have tests in place, not how they run 😉
@balazsbotond I wouldn't mind messing around a bit for option 3, if you need help. Might be better to compare some of the options if we have something to compare them against. It's a small lib, so shouldn't be too much work (famous last words?)
@SimonJang sounds great, I would really appreciate it!
In the meantime I started to write a POC for version 2 on the feature/qs-port
branch - this way we'll be able to compare the two versions.
I think option 3 may be the best choice. For use in Deno, you would import directly from a CDN like Pika, jspm, or unpkg.
The tsconfig.json as it is now likely could be updated to target ESM modules with the use of a bundler, but I'm unsure if it would allow imports within that module. That we can test out.
Update: You would need to bundle to continue using qs.
@tcarrio I also like option 3 the most.
@balazsbotond I haven't found much time the previous week to work on this. I'll give it a go this week.
@SimonJang thank you!
Closing because I don't have the time and motivation to change the currently published version significantly.
Until #51 was merged, urlcat was dependency-free and therefore it could trivially support Deno along with Node and the browser. This PR introduced qs as a dependency to support arrays and objects as query parameters and different ways of formatting them.
I asked a question on the Deno Discourse server and after discussing this situation with @wperron, I can see 4 options:
1. Create a completely separate version of urlcat based on the
2.x
branch specifically for Deno2. Fork qs
We could maintain our own fork of qs based on the TypeScript port here. qs is very mature and the release frequency isn't insane so each new version could be integrated into urlcat.
3. Use Rollup or webpack and target ESM as a transpilation target
Note from the Deno chat:
package.json
)4. Drop Deno support
@tcarrio, @3zk1m0, @knpwrs or anyone else who is interested - I would really appreciate if you shared your opinion about this.