NPM authenticate should be able to create .npmrc if it doesn't exist.

[atrauzzi]

Without the ability to do this, you force me to create a fairly arbitrary task just to make sure the file is there already.

[mitchdenny]

@zjrunner sounds like a reasonable request :)

[jotaylo]

It does sound like a reasonable request, however to add this feature it's not quite as straightforward as just creating the file. The task currently also looks at the existing .npmrc file, reads out the feeds, determines which ones are in the current organization, and then authenticates those.
If we extend the task to create a new .npmrc file, we'll need to add the ability to select feeds from the current organization.

[atrauzzi]

I'm not sure I understand how that would impact the simplicity of implementing the exact same thing I'm already doing with an extra task.

[atrauzzi]

Having some issues this morning with the NPM authenticate task, it seems as though you guys have altered its behaviour recently as one of my builds has now started failing without any change.
The assumption that an .npmrc file would already be in the project is a bad assumption to impose as this file ends up receiving sensitive information - both locally and on the build machine. You're effectively encouraging people to check into source control a file that really has no business being in source control.

The only workaround for this imposed workflow is to add it and then .gitignore it, which then makes updating the file with new repositories in the future a very brittle process.

The NPM authenticate task should accept a selection of repositories to enable and then create or update an existing .npmrc file at a sensible default location, or a customizable path for the job.

[jotaylo]

What issues are you seeing? I've got an open PR, but there haven't been any changes to the task in a few weeks.

In the next quarter we'll be concentrating on improving the auth experience in pipelines. We're starting those discussions soon, and I'll bring up your feedback - I agree with the proposal in your third paragraph.

[zjrunner]

@atrauzzi - in addition to what Jovana said/asked, what sensitive information goes to the checked-in npmrc by default? I've always seen the checked in npmrc used for uri and config, and creds go in %userprofile%.npmrc. Having base uri/config in source control does seem valuable and this auth-split is a pattern I see in many other protocols. https://www.npmjs.com/package/vsts-npm-auth reads one and writes to another by default for example. Curious if you just see people make mistakes a lot or if there is some default cred writing behavior out there.

[atrauzzi]

My concern isn't when people do use .npmrc. For the vast majority of JS projects though, there's no merit in having any kind of repository info in source control:

• Projects already identify their dependencies - including namespace - in package.json
• Mappings of credentials as well as any other behaviours are specific to the machine NPM is being run on, not globally across all checkouts of the repository
• Yeah, people are easily guided into making mistakes, this plugins current behaviour increases the likelihood of this
• Who wants to configure their repositories for every project they check out? I stick an .npmrc with my repo auth in my home directory and move on
• The directory cascade that .npmrc supports implies that configuration could (should) originate from multiple levels of the filesystem by way of the corresponding circumstances responsible for each directory level, ie:
  • Project, information necessary for all builds (this does not mean repo authentication)
  • [ insert any number of company specific conventions not related to this discussion ]
  • Machine, authentication and any adjustments for behaviour

It's premature to assume all projects will have an .npmrc. Many projects are fine with defaults and if this plugin disagrees with that assumption, then people are being forced to over-engineer configuration where all defaults sufficed.

I might have said this first to save time, but the tldr; is: The current behaviour conflates a build concern with a source control level concern.

[github-actions]

This issue is stale because it has been open for 180 days with no activity. Remove the stale label or comment on the issue otherwise this will be closed in 5 days

[atrauzzi]

Not stale.

[github-actions]

This issue is stale because it has been open for 180 days with no activity. Remove the stale label or comment on the issue otherwise this will be closed in 5 days

[atrauzzi]

Not stale.

[github-actions]

In order to consolidate to fewer feedback channels, we've moved suggestions and issue reporting to Developer Community.

[atrauzzi]

Not helpful.