I would like to suggest blessing a
package.json property to point to a Deno main file (and expose the fact of its presence, if not its value, via the npm API). I know npm is the Node package manager, but I think its future would be best served (not to mention better ensured) by supporting Deno which builds access restrictions in.
npm packages’ potentially unsafe command line
install scripts and such could be avoided by the Deno-consumers as well. (Since the whole package might not be needed, npm could make the installation of Deno (or Node) files more convenient by exposing to the npm API the download of individual files out of any package (or a Deno chain of rolled up TypeScript files!), but this is not critical.)
With an ability to find a Deno API, an application running Deno without flags and importing npm-hosted packages could import such modules directly or, if sandboxing were needed to avoid the current script’s privileges being passed on to the module, communicate via CLI calls with them (without flags), blocking dangerous network and file access on such untrusted packages through Deno’s default behavior.
package.json properties could also be added to indicate the level of access required (or optional), e.g., for network or file access, so that the minimal number of required appropriate Deno flags could be optionally added by a consuming application which trusted them (perhaps with an application even letting their users decide, especially useful if their application allowed extensibility to users through installation of arbitrary Deno-supporting npm packages).
With such features, developers and their users could gain the benefits of both worlds; the security of Deno, with the fixed and secure versioning of npm along with npm’s search capabilities (including its metadata). Developers need not be forced to choose between security or convenience, and could more easily and securely combine Node and Deno components.
(I have another recommendation for allowing the whole public TypeScript API of an application to be queried through npm search as well, which could grant applications foreknowledge (before downloading) of which npm packages could support, e.g., string-to-string conversions, HTML Blob to a Promise resolving to an array, etc…, for use not only by developers, but also by applications allowing npm installation to users, but this issue is more foundational, so I thought I’d start with this.)