Add support for setting flags globally and as config in package.json

[voxpelli]

We run across #248 (or something similar) repeatedly internally, so while we prefer yarn in most cases, we do want to avoid using yarn for the actual publishing of the package – npm feels much more stable there.

Using the --no-yarn flag solves that problem, but remembering to add it isn't as easy + it makes for a much more verbose command than just np.

Of course one could add an alias for it or something to get around it, but maybe there could also be a global config, like ~/.npconfig that could set such flags globally?

IssueHunt Summary

itaisteinherz has been rewarded.

Sponsors (Total: $40.00)

• issuehunt ($40.00)

Tips

• Checkout the Issuehunt explorer to discover more funded issues.
• Need some help from other developers? Add your repositories on IssueHunt to raise funds.

[voxpelli]

Any feedback on this @sindresorhus @SamVerschueren? I would be happy to help with a PR

An additional reason for this is: Yarn + OTP + np = 😢

[sindresorhus]

I'm willing to accept a PR for adding cosmiconfig, which would solve this, if someone is willing to help maintain np. Right now it's just me and I'm kinda burnt out by requests for all the things I would never use.

[voxpelli]

@sindresorhus I'll try to find time to take a look at it soon and could definitely help with maintaining it

[sindresorhus]

The config file should be named .np-config.json.

[IssueHuntBot]

@IssueHunt has funded $40.00 to this issue. See it on IssueHunt

[itaisteinherz]

@voxpelli Did you try adding a release npm script to your internal packages, which runs np --no-yarn?
Configuring np via a JSON config file sounds like a bit of an overkill to me, as the options suggested above should work just as well. Did you encounter any special use-case where the solutions suggested above don't solve the issue?

[itaisteinherz]

After reading Sindre's comment, I can see now why using config files is preferable in some cases. I'll start working on this 👌🏻

[itaisteinherz]

I'm willing to accept a PR for adding cosmiconfig, which would solve this

@sindresorhus @voxpelli Any specific reason to prefer cosmiconfig over pkg-conf? I'm still having trouble seeing how defining a global np configuration is going to be useful. It could also lead to unexpected issues where running np on different machines could produce different results.

[voxpelli]

It depends on whether you want np to function the same across all repos on your computer or whether you want it to function the same in your repo across all of your computers.

For me: I have like 80 repos and I don’t want to maintain a config in each one.

Though with cosmiconfig I can also share a config between 79 of them and have number 80 define its package specific way.

[sindresorhus]

I think we should separate global and local config. Global config, should only apply to the global np binary and never be inherited when using the local np binary, for example, in a npm run script.

[itaisteinherz]

Global config, should only apply to the global np binary and never be inherited when using the local np binary, for example, in a npm run script.

That would prevent the scenario I described above from happening 👍🏻

[itaisteinherz]

@sindresorhus From what you're describing, it also seems like we should also use import-local. Let me know if that's the case.
We could also implement the behavior you described using is-installed-globally.

[IssueHuntBot]

@sindresorhus has rewarded $36.00 to @itaisteinherz. See it on IssueHunt

• 💰 Total deposit: $40.00
• 🎉 Repository reward(0%): $0.00
• 🔧 Service fee(10%): $4.00