Private package folders with Yarn PnP

[cpojer]

Currently, in the JavaScript ecosystem, any file from a package can be required even if it is considered as private API by the package author, for example:

require('jest-haste-map/build/HasteFS'); // Works!

There is no way to hide private API besides compiling a project into a single flat bundle and only exposing the public API. Very few people choose to do this, and it may not be ideal in terms of load times – it may make sense for some packages to have two or three top level modules instead of one.

With Yarn PnP controlling the resolution algorithm it is now possible to prevent access to certain files and folders from other locations. There are two ways to pick a private folder:

• Either we standardize on a single folder name like private or similar, or
• we allow package authors to make files private by listing private folders (or public ones if we'd prefer to use a whitelist) of a package in package.json.

This would have the effect that only a limited subset of a package is available to the outside, while the package code can still be distributed in a manageable way.

Let me know what you think about this – feel free to create an RFC based on this idea or even better – send a Pull Request with a proposed implementation :)

[arcanis]

I think the best would be for the opposite: whitelisting instead of blacklisting.

While PnP did a lot to prevent useless I/O calls, some still are needed simply because of the extension resolution (lodash/foo -> lodash/foo.js) and folder resolution (lodash/fp -> lodash/fp/index.js). We could avoid it if we were keeping the full list of package files within the PnP file, but since it's a lot of data mostly useless I would prefer to avoid it.

But if we assume that packages explicitly describe their entry points, then the resolution can be done without any I/O - the algorithm would just have to check whether the resolution endpoints is meant to exist!

{
  "entrypoints": [
    "./fp/index.js",
    "./foo.js",
  ]
}

Or, if you don't want to allow access to anything else than the index (like in your case):

{
  "entrypoints": [
    "./index.js",
  ]
}

[cpojer]

Yep, as stated in the original comment, a whitelist is fine with me too. Either way, the same result is accomplished so I'm totally happy with this :)

[suchipi]

This would be great, common pain point 👍

[namuol]

I have written code to manually detect and prevent this; it would be great to have baked-in support.

Regarding whitelist vs blacklist: I'm probably on the extreme side of this, but I would prefer that we disallow importing anything other than main by default.

[merceyz]

Closing as this is solved by using the exports field now supported by node https://nodejs.org/api/packages.html#packages_exports