[Feature] Move config resolution to it's own package

[silverwind]

• I'd be willing to implement this feature
• This feature can already be implemented through a plugin

Describe the user story

Tools like https://github.com/rexxars/registry-auth-token and https://github.com/sindresorhus/registry-url need a way to access configuration settings like registry and auth tokens without having to re-implement yarn's config resolution mechanism.

Describe the solution you'd like

Move config resolution to its own package, e.g. @berry/config so that other modules can import and use it, e.g. import config from '@berry/config' should yield a configuration object for the current working directory.

Describe the drawbacks of your solution

Have to maintain one additional package.

Describe alternatives you've considered

None

Additional context

None

[arcanis]

We already have @berry/core which you can access as such:

import {Configuration}             from '@berry/core';
import npmPlugin, {npmConfigUtils} from '@berry/plugin-npm';

const configuration = await Configuration.find(__dirname, [npmPlugin], {strict: false});
const registry = npmConfigUtils.getDefaultRegistry({configuration});

console.log(registry);

Does that match what you have in mind? The plugins aren't published yet so you can't access npmConfigUtils at the moment, but it's something we could do (the main question is: do we want to actually publish them? or do we want consumers to be able to somehow require them directly from the local Yarn binary used by the project?).

[silverwind]

This seems like it could work, if access tokens are accessible too (I assume via getRegistryConfiguration). My use case is this module which needs to talk directly to the registries.

do we want to actually publish them? or do we want consumers to be able to somehow require them directly from the local Yarn binary used by the project?

yarn is not typically added to a project's dependencies, right? I certainly would not want to interface with a globally installed module, so my preference would be to publish the npm package. If the plan is to have a project depend on yarn (maybe as a devDependency), then of course I'm happy to import it from the local modules, but I guess there's a chicken-and-egg problem there if the package manager itself is a dependency.

Do you plan on having berry support parsing .npmrc like v1 does? If so, the process of obtaining registry configuration could be simplified to just getting it from yarn. Otherwise, I guess I would at least need the rc module to be able to support both npm and yarn.

[arcanis]

Sorry, I missed your answer:

Do you plan on having berry support parsing .npmrc like v1 does?

No, Berry exclusively reads the .yarnrc.yml files (even the v1 .yarnrc are ignored).

[arcanis]

Going to close for now as the OP request seems to be already possible, but feel free to keep the discussion going if you have other questions 🙂