You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Looking at these issues: Link 1, Link 2, Link 3 and more, there seems to be a general interest for a better system of managing dependencies and permissions. While I don't really have any opinions on whether that's necessary or how they should be elegantly implemented, the current recommendation is to create a deps.ts or import_map.json file to manage your dependencies from a centralised location while cleaning up your import statements.
A denox add command would be useful to automatically add new dependencies to an import map, either in the deno-workspace file or a separate import_map.json file. The denox run command could then include this import map when running a script (perhaps this could be the default behaviour with an option to opt-out of it with a flag).
Adding them to the workspace file would mean that denox doesn't have to deal with a second file, but then the import maps cannot be directly used by the standard deno CLI with the --import-map option. Also, I would assume that this would have to be limited to JSON and YML workspace files.
Thoughts? If this seems in line with the goal of this project, I'd be interested in working on a PoC.
The text was updated successfully, but these errors were encountered:
Issue Type
Description
Looking at these issues: Link 1, Link 2, Link 3 and more, there seems to be a general interest for a better system of managing dependencies and permissions. While I don't really have any opinions on whether that's necessary or how they should be elegantly implemented, the current recommendation is to create a
deps.ts
orimport_map.json
file to manage your dependencies from a centralised location while cleaning up your import statements.A
denox add
command would be useful to automatically add new dependencies to an import map, either in the deno-workspace file or a separateimport_map.json
file. Thedenox run
command could then include this import map when running a script (perhaps this could be the default behaviour with an option to opt-out of it with a flag).Adding them to the workspace file would mean that denox doesn't have to deal with a second file, but then the import maps cannot be directly used by the standard deno CLI with the
--import-map
option. Also, I would assume that this would have to be limited to JSON and YML workspace files.Thoughts? If this seems in line with the goal of this project, I'd be interested in working on a PoC.
The text was updated successfully, but these errors were encountered: