project's .npmrc not respected

Right now if you have an .npmrc at the project root that is not respected but rather the following piece of code just checks the .npmrc in the HOME directory

action/src/index.ts

Lines 44 to 53 in cd904b9

    
           let npmrcPath = `${process.env.HOME}/.npmrc`; 
        
           if (fs.existsSync(npmrcPath)) { 
        
             console.log("Found existing .npmrc file"); 
        
           } else { 
        
             console.log("No .npmrc file found, creating one"); 
        
             fs.writeFileSync( 
        
               npmrcPath, 
        
               `//registry.npmjs.org/:_authToken=${process.env.NPM_TOKEN}` 
        
             ); 
        
           }

Even the ideal flow for npm or any process is they check for .npmrc at the project root if not then they look for .npmrc in the HOME directory.

Update index.ts

~~I don't think this .npmrc is even being used by changesets.~~

I found that using action/node-setup and the registry-url you need to set NODE_AUTH_TOKEN

I had to replace my env.NPM_TOKEN with env.NODE_AUTH_TOKEN because I'm using actions/node-setup and changesets is working fine without the NPM_TOKEN.

Update Explanation: actions/setup-node creates an auth file when the registry-url exists and uses NODE_AUTH_TOKEN then puts that path in the NPM_CONFIG_USERCONFIG environment variable. I believe this now overrides the use of the .npmrc file and why it's not used.

https://github.com/actions/setup-node/blob/78148dae5052c4942d5b0f92719061df122a3b1c/src/authutil.ts#L41

I wonder if changesets/action should maybe check for NPM_CONFIG_USERCONFIG existing before it writes out the .npmrc file and/or log out an explanation.

Maybe someone can explain if this is true or clear up any misunderstanding.

Add NODE_AUTH_TOKEN for release workflow (#1242)

ci: Update release workflow

For a CI action to be hard-coded to only check $HOME/.npmrc is pretty bad imo. At least self-hosted runners are often stateful, and potentially concurrent, so adding files to a shared directory should be avoided. Especially since the action doesn't clean up after itself.

As a workaround I opted to change the $HOME variable during the run. Not ideal, but it appears to work just fine. ~~If someone knows how to set $HOME using jobs.steps.env, then that would be even better.~~

  # changesets/action presumes the .npmrc is in $HOME
  # See:
  # - https://github.com/changesets/action/issues/58
  # - https://github.com/changesets/action/blob/2bb9bcbd6bf4996a55ce459a630a0aa699457f59/src/index.ts#L58
  - name: Set HOME
    run: echo "HOME=$(pwd)" >> $GITHUB_ENV

Edit: use jobs.steps.env like this, as shown in #147

env:
    HOME: ${{ github.workspace }}

@nikparo

@nikparo agree with this. I ran into this today. It's also weird that the action forces a check to make sure the default npm registry token is configured. (full on assumes that packages are being published to the public registry alone)

@nikparo

@nikparo #147 the solution this guy presents here is a little cleaner if this interests you...

Navigation Menu

Repository navigation

project's .npmrc not respected #58

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	let npmrcPath = `${process.env.HOME}/.npmrc`;
	if (fs.existsSync(npmrcPath)) {
	console.log("Found existing .npmrc file");
	} else {
	console.log("No .npmrc file found, creating one");
	fs.writeFileSync(
	npmrcPath,
	`//registry.npmjs.org/:_authToken=${process.env.NPM_TOKEN}`
	);
	}

project's .npmrc not respected #58

Description

Activity

talves commented on Nov 16, 2020

talves commented on Nov 16, 2020

nikparo commented on Jan 27, 2024

yashsway commented on Sep 17, 2024

yashsway commented on Sep 17, 2024

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions