Deno package management questions.
I have a few questions regarding package management in Deno.
1. Here Deno documentation states that import maps are only applied to applications, and that library authors should prefer the deps.ts pattern.
Contrarily, the jsr documentation specifies that a dependency manifest like the import map in the deno.json file can be used by a library. Does this mean that the deps.ts pattern is now obsolete?
2. How do I use packages published with jsr in a browser environment? Using esm.sh, I can do
import ... from "https://esm.sh/preact@10.21.0". Can I do the same with jsr?
3. In jsr, all entry points have to be specified explicitly, so we no longer need to add a package with a trailing slash in the import map to import modules beyond the default entry point. Is this correct?
4. How do I replicate a configuration like this in jsr, specifically specifying external dependencies and aliases?
2 Replies
1. Regarding the use of
deps.ts versus import maps, the documentation does not explicitly state that the deps.ts pattern is obsolete. Instead, it highlights the benefits and limitations of both approaches. The deps.ts pattern is a convention in the Deno ecosystem for managing remote dependencies by re-exporting them from a single file. This makes it easier to manage and update dependencies. On the other hand, import maps allow for the use of bare specifiers and can simplify the process of importing modules. However, import maps are not composable, which means that a library cannot use both bare specifiers and an import map simultaneously, as the top-level project importing that library cannot compose the library’s import map with its own. Therefore, library authors should still use regular, non-bare specifiers (relative or absolute file/HTTP URLs) to ensure compatibility with users' import maps. 🦕
2. For using packages published with jsr in a browser environment, the documentation does not provide a direct example of importing jsr packages in the browser. However, if jsr packages are available via HTTP URLs, you could import them in a similar fashion to how you would with esm.sh, provided that the jsr package is hosted on a server that is accessible from the browser and supports the necessary CORS headers.
3. In jsr, specifying all entry points explicitly does indeed mean that you no longer need to add a package with a trailing slash in the import map to import modules beyond the default entry point. The documentation mentions that the deno: URL scheme will be introduced to handle semver resolution and module deduplication, which simplifies the import process without the need for trailing slashes.
4. Replicating a configuration that specifies externaldependencies and aliases in jsr is not directly addressed in the documentation. The documentation does not provide an example of how to specify external dependencies and aliases within jsr or import maps. However, it does mention the ability to remap regular specifiers to different ones using import maps, which could potentially be used to achieve a similar outcome. For specific syntax and capabilities, you would need to refer to the jsr documentation or the import maps specification for more detailed information.
Remember that the Deno ecosystem is evolving, and new features and best practices may emerge over time. It's always a good idea to refer to the latest documentation for the most up-to-date guidance. 🦕