First of all, thank you for your work on superoak! It's an incredibly useful library for testing Oak applications.
I am currently working on an Oak middleware that I intend to publish on JSR. However, JSR only allows dependencies from trusted sources like NPM or JSR, and direct imports from https://deno.land/ are not permitted ( invalidexternalimport ).
While it is possible to manually download superoak and include it in my project each time I develop middleware, this approach is not ideal and can be cumbersome. It would be much more efficient if superoak were available on a trusted registry like NPM or JSR.
Would you consider publishing superoak to NPM or JSR to make it more accessible for developers who are restricted to these registries? It would greatly help those of us who want to use superoak but are limited by these constraints.
Thank you for considering this request, and I look forward to your response!
Update:
I have also noticed that setting up a dedicated directory within my project for testing and using superoak as a dependency there does not cause issues when publishing a package. However, I believe that all dependencies should be managed centrally in the deno.json file for consistency and maintainability.
Hello,
First of all, thank you for your work on superoak! It's an incredibly useful library for testing Oak applications.
I am currently working on an Oak middleware that I intend to publish on JSR. However, JSR only allows dependencies from trusted sources like NPM or JSR, and direct imports from
https://deno.land/are not permitted ( invalidexternalimport ).While it is possible to manually download superoak and include it in my project each time I develop middleware, this approach is not ideal and can be cumbersome. It would be much more efficient if superoak were available on a trusted registry like NPM or JSR.
Would you consider publishing superoak to NPM or JSR to make it more accessible for developers who are restricted to these registries? It would greatly help those of us who want to use superoak but are limited by these constraints.
Thank you for considering this request, and I look forward to your response!
Update: I have also noticed that setting up a dedicated directory within my project for testing and using superoak as a dependency there does not cause issues when publishing a package. However, I believe that all dependencies should be managed centrally in the
deno.jsonfile for consistency and maintainability.