<h2 dir="auto">Background</h2>
<p dir="auto">I am the developer of an a new framework for writing Telegram bots (<a href="https://github.com/grammyjs/grammY">ref</a>, but the purpose is irrelevant here). The core framework is extensible by plugins that can be published by other authors. As a result, I publish one core package to <a href="https://deno.land/x" rel="nofollow">deno.land/x</a>, and other people and me publish other packages around it.</p>
<h2 dir="auto">Problem Description</h2>
<p dir="auto">While it would be desirable that plugins do not depend on the core module, this is not always possible. Some plugins rely on different parts of the core package (both runtime code and some complicated type transformations) that are also exposed to users, and it makes little sense to duplicate this logic into each plugin.</p>
<p dir="auto">Even if it is possible to achieve duplicate only some parts of the core library, and let maybe users pass in the missing components, this is not always practical and can lead to unnecessarily complex code.</p>
<p dir="auto">Right now, some of the plugins specify the grammY core package as a direct dependency, but this can lead to users downloading multiple versions of the same package.</p>
<h2 dir="auto">How Node Solves It</h2>
<p dir="auto">For an npm package, this would be solved by making the core package a peer dependency with specified semver ranges that are supported. This pattern can be seen a lot in the npm ecosystem, and while peer deps are generally to be avoided, they sometimes have their place.</p>
<h2 dir="auto">One of the Solutions</h2>
<p dir="auto">It would be nice to be able to specify semver ranges in import URLs, à la</p>
<div class="highlight highlight-source-ts notranslate position-relative overflow-auto" dir="auto" data-snippet-clipboard-copy-content="import { Bot } from 'https://deno.land/x/grammy@v^0.4.0||^1.0.0/mod.ts'"><pre class="notranslate"><span class="pl-k">import</span> <span class="pl-kos">{</span> <span class="pl-smi">Bot</span> <span class="pl-kos">}</span> <span class="pl-k">from</span> <span class="pl-s">'https://deno.land/x/grammy@v^0.4.0||^1.0.0/mod.ts'</span></pre></div>
<p dir="auto">but I don't mind the exact syntax being different.</p>
<p dir="auto">I am by far not the first person to mention this, and it is neither flawless nor the only solution. However, despite some people commenting on the problem, I cannot find a promising suggestion on how to overcome this issue. I looked into ways of restructuring the plugin architecture, but I always ended up at the point that at least one of the plugin packages needed to refer to the core package in some way or another, or at least parts of it.</p>
<p dir="auto">Please let me know if I overlooked a GitHub issue somewhere that discusses this. If that does not exist, what are you suggesting how to handle these situations?</p>