[katelynsills]

This is a really good question. You would want to ensure that the templating library cannot get access to the http request library unless the templating library is explicitly given a reference to it. So even though both libraries are imported, they can't access each other by default. Realms (the standards track proposal [1]) lets you do this, and Salesforce uses it right now as the security kernel that ensures that their third party apps can't view or mess with other apps [2].

The best way to enforce POLA, and especially this particular problem of not allowing libraries to have access to each other, is object capabilities (ocaps) [3]. An object capability combines designation with authority -- if you have access to a capability, you can use it. If you don't have access, you can't use it. You can think of this (very roughly) as a key to a car as opposed to your name being on a guest list for a party. I didn't really touch on ocaps in this piece, but it's a necessary component for being able to enforce POLA well.

[1] https://developers.google.com/caja/

[2] https://www.youtube.com/watch?v=3ME7oHHQbuM

[3] http://habitatchronicles.com/2017/05/what-are-capabilities/

[arcatek]

Worth noting that the principle of "a package can only access the dependencies it declared" is already something that we (Yarn) are pushing through Plug'n'Play.

We're not focused on security (yet), but any help we can get to move the ecosystem towards a stricter model will help you in the long term (by ensuring that common tools will be compatible with the even stricter model you're advocating).

[1] https://github.com/yarnpkg/rfcs/pull/101

[katelynsills]

Sorry, [1] should be https://github.com/tc39/proposal-realms