Publishing (and configuring) the webhook for deno.land from monorepo
Thanks in advance for your help!
I went through the setup on https://deno.com/add_module for my jupyter project anywidget (https://github.com/manzt/anywidget/pull/311) to support module for
deno jupyter. Anywidget is a monorepo of a Python package and associated front-end JavaScript modules. I have github actions setup to make a separate tagged release for each sub-package, and would like to similarly support the deno module I created for interfacing with these front-end modules.
- Is it possible to configure a different sub-path within the repo? (I'm not sure I did this correct, or may want to move mod.ts)
- I'm not sure how the deno mod.ts will get published for other tagged releases of different packages. Is is possible to publish this separately?
I'd ideally like to keep these all in the same repo, but understand if that is not possible. In that case, is it possible to transfer anywidget from deno.land (which I grabbed) to a separate repo?GitHub
accept imports in deno anywidget by rgbkrk · Pull Request #311 · ma...
This is a rough way to include imports, which could be a general preamble instead.
import { widget } from "./mod.ts";
let model = await widget({
// shared model between frontend and ...
6 Replies
Based on the documentation, Deno is not prescriptive about how developers make their modules available—modules may be imported from any source. However, to publish Deno modules via the official deno.land/x hosting service, modules must be developed and hosted in public repositories on GitHub. Their source is then published to deno.land/x on tag creation.
To answer your questions:
1. Configuring a different sub-path within the repo: The documentation does not provide explicit information on configuring a different sub-path within the repo for the Deno module. However, the module can be accessed by using a URL in the following format:
https://deno.land/x/<module_name>@<tag_name>/<file_path>. This suggests that you can specify a sub-path in the <file_path> part of the URL.
2. Publishing the mod.ts for other tagged releases: The documentation states that module versions are persistent and immutable. It is thus not possible to edit or delete a module (or version), to prevent breaking programs that rely on this module. However, it does not provide explicit information on publishing the mod.ts separately for other tagged releases of different packages.
3. Keeping all in the same repo: The documentation does not provide explicit information on whether it's possible to keep all modules in the same repo. However, it does state that modules must be developed and hosted in public repositories on GitHub, suggesting that each module should have its own repository.
4. Transferring anywidget from deno.land to a separate repo: The documentation does not provide explicit information on transferring a module from deno.land to a separate repo. However, it does state that modules may be removed if there is a legal reason to do so (for example copyrightinfringement).
Please note that the information provided here is based on the documentation's opinion and may not cover all possible scenarios or use cases. For more specific or complex questions, it might be best to reach out to the Deno community or maintainers directly.
This isn't exactly what I needed.
Silly bot. @bartlomieju who's the right person to reach out to about figuring out deno.land registry issues?
Just noticed this comment: https://discord.com/channels/684898665143206084/1158338786393079849/1158414995923677375
Email modules@deno.com
Sorry, was out for a few hours. Yeah the email above is go to solution 🙂
Thank you so much!!!
If anyone finds this in the future, you can use the
subdir and version_prefix search params for the webhook to configure where the root directory for your deno module lives and what tags trigger releases.