Does Deno third party modules support to wrap NPM in importmap
Here is my first module: https://deno.land/x/lume_fluent@1.0.0-alpha
My importmap for the module is
It works ok in my local but when failed if I load it from Deno/X, what should I do to fix this case? I prefer to use importmap so I can easily manage deps' ver.
4 Replies
Based on the documentation, Deno does support the use of import maps to manage dependencies, including npm packages. However, there are a few things to consider:
1. The import map should be specified in the
deno.json configuration file. This file is auto-discovered by Deno and acts as an import map among other things.
2. The import map should map the bare specifier (like "npm/fluent") to the actual URL of the module. In your case, you're mapping "npm/fluent" to "npm:@fluent/bundle@0.18.0", which seems to be an npm specifier. Instead, you should map it to the actual URL where the module can be found. For example, if you're using esm.sh as a CDN, it would look something like this:
3. If you're using code both with Deno and Node.js, the node: scheme will work in both runtimes and it’s recommended to update to them for your Node.js code.
4. If you're still having issues, it might be helpful to provide more information about the error message you're seeing. This could help identify if there's a problem with the module itself, or if there's an issue with how Deno is resolving the import.
Remember, this advice is based on the documentation and might not cover all possible issues. If you're still having trouble, it might be worth reaching out to the Deno community for more specific advice. 🦕import maps only work locally in the module. If you publish a library with an import map and the local project where you're trying to use the published library doesn't have the same mappings it will fail. For that reason modules published to the deno registry must not use the import map in files they expose. We're working on a solution for that, but there is no ETA
to add, a common solution is to have a deps.ts file where you re-export your external libraries. then refer to the deps.ts in your actual imports. this way you can manage the versions centrally in the deps.ts file. a possible drawback is that all dependencies in deps.ts will be loaded whether your current entry point actually use them or not whereas import map works more nicely in an as needed basis.
I guess I'll have to go with
deps.ts for now as my module is not to big to concern about that problem 😄 Thanks for support guy