3 ms·

I broadly agree, but if I'm reading your suggestion correctly I think that "access" list is too coarse-grained still! It looks like you're suggesting a predefin

I broadly agree, but if I'm reading your suggestion correctly I think that "access" list is too coarse-grained still! It looks like you're suggesting a predefined list of permissions that can be granted to a dependency, but... why not go even further? If the list of things you're passing in are references rather than strings, then you could do... const apollo = require('apollo-client', {fetch}); const stringutils = require('stringutils'); That way, you can pass in at a very fine-grained level any object you want to, including things like `fetch` and `fs`. But then, you could just as easily pass in a custom `loggedFetch` module like so, that wraps `fetch` and logs all network requests made: const apollo = require('apollo-client', {fetch: loggedFetch}); This is the object-capability security model, and as a sibling commenter pointed out, LavaMoat basically does this for JavaScript dependencies. (This is also basically just lexical scope, by the way, if your language is strict enough - though most unfortunately aren't.)

FractalHQ 4y ago
I love this idea. But what about peer deps? And their dependencies? What if multiple deps share peer deps? Is there a simple way permissions could be resolved in the web of modules? Also- tangential but I really wish people would stop using require and use ESM whenever possible. I cringe when I see `require` just as much as when I see `var` being used in 2022, but I’m not certain there’s never a good reason not to use ESM.
- nirimda 4y ago
  If you want to override the dependency of your dependency, then it's your dependency too - so if you were using the javascript approach up there you might have var bar = require("bar", {baz: loggingBaz}) var foo = require("foo", {bar}) This is true even if you never otherwise use bar. This is certainly how peer dependencies work in nix flakes, for instance, where you can say something like bar = //.... bar.inputs.baz.follows = loggingBaz; foo = //.... foo.inputs.bar.follows = bar; Since nix flakes is a package/dependency manager, it generates a lockfile that you could inspect too see what all the dependencies are, and make sure you got it right (oh, I still have two bar's, I must have forgotten to override some other dep). I suppose any compiler that involves a linking stage would in principle be able to generate some comparable output at the language level. (Apologies for using require and var, but I'm convinced the functional syntax is semantically clearer in this context.)

FractalHQ 4y ago

I love this idea. But what about peer deps? And their dependencies? What if multiple deps share peer deps? Is there a simple way permissions could be resolved in the web of modules? Also- tangential but I really wish people would stop using require and use ESM whenever possible. I cringe when I see `require` just as much as when I see `var` being used in 2022, but I’m not certain there’s never a good reason not to use ESM.

nirimda 4y ago
If you want to override the dependency of your dependency, then it's your dependency too - so if you were using the javascript approach up there you might have var bar = require("bar", {baz: loggingBaz}) var foo = require("foo", {bar}) This is true even if you never otherwise use bar. This is certainly how peer dependencies work in nix flakes, for instance, where you can say something like bar = //.... bar.inputs.baz.follows = loggingBaz; foo = //.... foo.inputs.bar.follows = bar; Since nix flakes is a package/dependency manager, it generates a lockfile that you could inspect too see what all the dependencies are, and make sure you got it right (oh, I still have two bar's, I must have forgotten to override some other dep). I suppose any compiler that involves a linking stage would in principle be able to generate some comparable output at the language level. (Apologies for using require and var, but I'm convinced the functional syntax is semantically clearer in this context.)