-2

I tried to host my library for deno users on deno.land.

Afterwards, I found out about Deno's fight with Typescript/Node/ES Council about filenames. I went to the Deno discord, and they said that I couldn't actually publish my Typescript code in a way that would work both on Deno and under Typescript, because of file extensions.

So, I tried the es6 version; same thing.

So I tried the minified version, but deno just crashes with stack problems.

I'm not able to get any of the working builds in my library to work under Deno.

I asked the Deno staff to un-list the module, since it had only been up for an hour, but they refused.

I can't find a way to deprecate the module.

How do I warn deno users not to attempt to use my library? I don't want people wasting time on something that looks like it works, but doesn't.

Edit: hi, my question is about how to deprecate or unlist a module. I'm not here for more argument about how to change my code or become deno-centric, thanks.

John Haugeland
  • 9,230
  • 3
  • 37
  • 40
  • 2
    There's [a clear notice on the module registry page regarding the non-removal policy](https://deno.land/x#:~:text=Can%20I%20edit%20or%20remove%20a%20module): "Can I edit or remove a module on deno.land/x?: 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. Modules may be removed if there is a legal reason to do (for example copyright infringement)." – jsejcksn Jun 24 '22 at 17:25
  • Regarding making [your code](https://github.com/StoneCypher/jssm) ESM-compatible: Currently it is not because you use bare module specifiers which can only be resolved by TypeScript/Node (or require an import map in a browser/Deno). You can use valid ESM specifiers (which resolve to actual files/resources — e.g. `"./module.js"` instead of `"./module"`). TypeScript, Node, and Deno all support full ESM specifiers. – jsejcksn Jun 24 '22 at 17:30
  • The question I was asking isn't either of those, but thanks – John Haugeland Jun 24 '22 at 17:33
  • What I'm actually asking is how to leave deno gracefully, and not waste anybody's time with a non-working module, without polluting the release chain servicing so many other things. – John Haugeland Jun 24 '22 at 17:33
  • "TypeScript, Node, and Deno all support full ESM specifiers" Well, the core team people in the discord said this wouldn't work, and I can't make it work in Typescript. I'm long past the point of wanting to, besides. I just want to leave now. If you would like to continue to answer, please focus on my actual question, which is "how do I deprecate or unlist" – John Haugeland Jun 24 '22 at 17:34
  • "_Well, the core team people in the discord said this wouldn't work_": I can't a record of your conversation, but it appears that there was a discussion about import specifiers last night and [the original asker deleted all of their messages](https://discord.com/channels/684898665143206084/689420767620104201/989737849895133184). The users in the help channel appeared to respond differently than you claimed. – jsejcksn Jun 24 '22 at 18:18
  • 1
    There are lots of individuals here (myself and [the person who provided an answer](https://stackoverflow.com/a/72747035/438273) included) who want to help you succeed in your efforts. The `deno.land/x` registry is immutable and append-only (except for legally-compelled reasons), so the only way to modify what's there is to append new content by updating the content in the repository (that you voluntarily connected by adding a webhook), then creating a new git tag in the GitHub repo so that the webhook executes and the registry updates with the new content. There are no alternatives. – jsejcksn Jun 24 '22 at 18:23
  • Afterward, you can remove the webhook from your repo and no future activity will affect the contents at the `deno.land/x` registry. – jsejcksn Jun 24 '22 at 18:24
  • 1
    If you need to disable other webhooks, CI/CD, GitHub Actions, etc that you want to avoid interacting with when making to your "deprecation notice" changes and tag, that's something you'll have to think through and modify before and afterward — you haven't explained any of those details. – jsejcksn Jun 24 '22 at 18:32
  • However, rather than just give up, I think this is a great opportunity for you to learn more about module resolution, TypeScript, Node, and ESM, and to provide a browser- and Deno-compatible version of your codebase so that more users can benefit from your work. Just my 2¢. – jsejcksn Jun 24 '22 at 18:36
  • This is not related to my question. (Someone keeps deleting my saying this, preventing me from getting relevant help.) – John Haugeland Jun 25 '22 at 14:49

1 Answers1

1

I suggest publishing a "final" version to Deno with an updated README explaining that the project there is not to be used as is. You can provide links to elsewhere too (e.g. a package on NPM).

If you decide you want to be able to publish to Deno, NPM, and CDNs for browsers (e.g. Skypack) then you could update your file paths, dependencies, etc. and make your project a Deno-first project and then use dnt: Deno to npm package build tool (automated with GitHub Actions, etc.).

This way you can opt into the Deno platform and make your library available to NPM and CDN users too (such as Skypack and similar CDNs make compatible NPM packages available to browsers).

mfulton26
  • 29,956
  • 6
  • 64
  • 88
  • Maybe I'm misunderstanding, but wouldn't that mean I'd have to put my Deno warning on all the other platforms I'm using? – John Haugeland Jun 24 '22 at 16:44
  • Also, *please* stop trying to say that I should convert my project to be deno first I'm in the process of trying to leave – John Haugeland Jun 24 '22 at 16:45
  • You can publish your "final" "Deno-friendly" version just to deno.land (if you have CI/CD stuff set up for NPM you might want to disable that temporarily) and then you can remove any automated publishing to Deno to severe ties after which you will be able to restore your README and continue on without any deno.land publishing, etc. – mfulton26 Jun 24 '22 at 16:48
  • There is no deno friendly version. It never worked on deno. – John Haugeland Jun 24 '22 at 16:52
  • > Also, please stop trying to say that I should convert my project to be deno first I'm in the process of trying to leave You sound annoyed. This is my first interaction with you on this subject to my knowledge. I meant no pushing, I simply wanted to make you aware of alternatives in case you were interested. – mfulton26 Jun 24 '22 at 16:52
  • "You sound annoyed." I am. I said "how do I leave" and you said "switch to us and leave everyone else." I said "I just want to deprecate because it doesn't work" and you said "publish the good one." – John Haugeland Jun 24 '22 at 16:52
  • Yes, that is why I put it in quotations. What I'm suggesting is that you publish one last time to deno.land with a README that states, "don't use this from deno.land; it is not support; use NPM, etc." – mfulton26 Jun 24 '22 at 16:53
  • I don't feel that this discussion is productive, or moving towards an answer to my actual question. Thank you for your time. – John Haugeland Jun 24 '22 at 16:53
  • "What I'm suggesting is that you publish one last time to deno.land with a README that states" I don't want to, because that pollutes everything else, such as my release chain, and there's no way to prevent that. It is very unfortunate that Deno doesn't even have a working deprecation mechanism, and hard-refuses to un-list modules. This is community hostile. – John Haugeland Jun 24 '22 at 16:54