The future of Deno support
balazsbotond opened this issue · 10 comments
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 Deno
- pros:
- very easy to support Deno
- we don't need to check intercompatibility for each change we make, like we would do with a single codebase
- cons:
- no rich array/object formatting options in the Deno version
- maintenance overhead of having to support 2 libraries that do something very similar
2. 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.
- pros:
- we could only use the files needed for stringification - less bloat
- single codebase for Deno, Node and the browser
- Deno version is full-featured
- cons:
- maintenance overhead of integrating each new version of qs into urlcat
- we need to check intercompatibility for each change we make
3. Use Rollup or webpack and target ESM as a transpilation target
Note from the Deno chat:
I've never tried it, but be sure to check the imports generated by the bundler, Deno will require imports to have the file extension in order to work
- pros:
- updating qs is much easier than with the previous option (just change
package.json) - bundlers support tree shaking - less bloat
- single codebase for Deno, Node and the browser
- Deno version is full-featured
- if we already use a bundler, it would be trivial to generate a zip/CDN version of urlcat for the web
- updating qs is much easier than with the previous option (just change
- cons:
- we need to check intercompatibility for each change we make
- much more complicated build system
4. Drop Deno support
- pros:
- zero maintenance overhead of supporting Deno
- we don't need to check intercompatibility for each change we make
- cons:
- urlcat wouldn't be available on a platform which is getting more popular and could be the next big thing in the js world
@tcarrio, @3zk1m0, @knpwrs or anyone else who is interested - I would really appreciate if you shared your opinion about this.
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.