Comments (11)
does this mean that the trouble you faced is resolved in your case?
Yep!
honestly appreciate the persistence ... since #437
ya no problem.
what i'm not clear about from your statement is what you mean about "bad concat'ing".
Indeed, I should have used more precise language. I intended to mean "[referring my point] that some found files should not be concat'ed because of the mismatch with default npm behavior".
Edit: I realized you did grok my point above 😵 , so my expansion below wasn't needed :)
- We use the
rc
lib to take a best guess at what thenpm
config is here:Line 11 in 86011db
.npmrc
that npm itself would not include. - This line
Line 18 in 86011db
- We then concatenated it and used it
Line 21 in 86011db
...so, npm
complained and said "@cdaringe, my friend, this is bad _auth" and i said to it, "sir! sir! surely you are mistaken!" But it was not mistaken 😄
from npm.
Awesome, ya let's close!
from npm.
What versions are you using of semantic-release and the npm plugin?
from npm.
from npm.
Ok, i've learned some more.
- in my working checkout dir,
npm config list
reads data from<workspace>/.npmrc
and my<prefix>/globalconfig
. - when sem-rel processes, it thinks my configs are
<workspace>/.npmrc
and../../<workspace>/.npmrc
, which is a grantparent. More specifically:
13:04:37 "configs": [
13:04:37 "/mnt/jenkinspan/.npmrc", # this config file is not processed by npm list config when run in my project checkout
13:04:37 "/mnt/jenkinspan/workspace/myorg/foo/ws/.npmrc"
13:04:37 ]
// set-npmrc-auth.js
import rc from "rc";
rc();
tldr, sem-rels use of rc() writes an incompatible npm config with my system, where if it used just my checkout's npm config, it would work successfully. rc
does not appear to match the way npm sources configuration files? still digging.
My intuition says that this config generation method creates opporitunity for desync.
Instead of reading files and checking for valid auth, we should seriously consider querying npm to produce it's full configuration. We're we to have captured npm config list
as the source of config before calling verify-auth, it would have said "ya, this system is auth ready." However, instead of consulting npm, we tried to re-create what npm does, but it was not aligned, and can lead to two different failures:
- first, reading in a previously unread file (which corrupted my config), and second,
- not consulting the prefix/global config file (which dropped my critical, correct auth config!)
from npm.
tldr, sem-rels use of rc() writes an incompatible npm config with my system
the npm plugin used to write a config that use the _auth
approach that your error describes. this is because it used to be a valid approach. however, we dropped support for that approach in v10.0.0 of the npm plugin once npm dropped support. this is why i was curious about what versions you were using.
since you are using a version that is significantly newer than that change, it does not directly explain your problem. does the version you mentioned above match the one in the release workflow output? this feels like you have another (older) version of semantic-release involved somewhere.
also, are NPM_USERNAME
and NPM_PASSWORD
provided to your release workflow as environment variables?
from npm.
Instead of reading files and checking for valid auth, we should seriously consider querying npm to produce it's full configuration. We're we to have captured
npm config list
as the source of config before calling verify-auth, it would have said "ya, this system is auth ready." However, instead of consulting npm, we tried to re-create what npm does, but it was not aligned, and can lead to two different failures:
- first, reading in a previously unread file (which corrupted my config), and second,
- not consulting the prefix/global config file (which dropped my critical, correct auth config!)
i wont disagree that there is opportunity for improvement, but there are reasons that the auth process is how it is today. our goal is to leverage npm config as much as possible, but it is important to understand that auth is expected to be provided in the NPM_TOKEN
environment variable. if this is done as expected, semantic-release will produce a valid config that factors in the remaining config from your project .npmrc
with auth injected correctly.
from npm.
npm plugin once npm dropped support ... does the version you mentioned above match the one
The error message is directly from sem-rel running of the latest version of npm
(latest at the time of writing). And indeed, I can assert latest versions of all sem-rel packages were being used. The failure mode is/was isolated to the latest version of the npm sem-rel plugin (this package).
This package can generate an incorrect .npmrc, used in its temdir. My CI system had an old, incorrect evil floating .npmrc file on disk somewhere in a parent folder, which I did not place, nor do I service as a user of this CI system. I talked with the CI admin to remove it. NPM_TOKEN or no NPM_TOKEN, this package has code which concats all parent npmrcs which is no longer correct behavior, ref https://docs.npmjs.com/cli/v7/configuring-npm/npmrc#files
I think we're aligned on that, but re-expressing just for clarity sake.
but it is important to understand ... if this is done as expected
This is incorrect. The following is all stated with courtesy. This lib currently supports checking for _auth
, and can fail incorrectly due to bad concat'ing. "done as expected" is surprising language given the state of the code. The lib supports this now despite the unsupported claim:
Lines 21 to 26 in 86011db
Even if I had set NPM_TOKEN, that failing code block would have triggered and my publish failed due to the rc
concatenating in a dead rc file. FWIW, I do rely on my auth being provided by my CI providing team, so NPM_TOKEN
isn't available to me, which is... a thing 😵 .
It's a subtle and nuanced failure mode, no doubt.
from npm.
My CI system had an old, incorrect evil floating .npmrc file on disk somewhere in a parent folder, which I did not place, nor do I service as a user of this CI system. I talked with the CI admin to remove it.
does this mean that the trouble you faced is resolved in your case? if so, that gives us a bit of space to gather the details more clearly for improving the future handling of the configs
NPM_TOKEN or no NPM_TOKEN, this package has code which concats all parent npmrcs which is no longer correct behavior, ref docs.npmjs.com/cli/v7/configuring-npm/npmrc#files
as i mentioned, our goal is to align with npm as closely as possible, but we know we are currently not fully in alignment. appreciate you highlighting the details that you found that resulted in misalignment and surprise. i'll open an issue to track this separately
This is incorrect. The following is all stated with courtesy.
honestly appreciate the persistence to get the right details in the open. i'll be honest, i've never provided auth through an .npmrc when using semantic-release, so i forgot that we supported that approach officially. for a long time, the env var was the only supported method of providing a token. i understand the cases where it fits how some teams prefer to configure CI servers, but i honestly thought we hadnt added that support yet. i can say with certainty that we no longer inject auth as _auth
since that was removed as part of #437
This lib currently supports checking for
_auth
, and can fail incorrectly due to bad concat'ing.
i'm still a little bit confused here, so i'm hoping to just clarify some specifics. since it has been a bit since i've explored this particular part of our implementation for a while, i looked a little more closely. i see that registry-auth-token does find and return a token from an .npmrc file that uses the legacy unscoped approach. what i'm not clear about from your statement is what you mean about "bad concat'ing". are you saying that the approach of combining the files is introducing a syntax or formatting error, that the _auth
property should be stripped, or is this referring to your point that some found files should not be concat'ed because of the mismatch with default npm behvaior?
from npm.
i'll open an issue to track this separately
from npm.
got it. that makes sense.
I realized you did grok my point above 😵 , so my expansion below wasn't needed :)
i do appreciate the confirmation so that i know for sure we are on the same page now
i agree that we should address this, and i think i have this covered in the additional issues created as a result of this thread. since you have a path forward with the current state of things, would it be fair to close this issue in favor of the others to address aligning better with current npm behavior?
from npm.
Related Issues (20)
- `package.json` version not updated, despite correct plugin ordering HOT 1
- Set --no-workspaces with npm version HOT 2
- Command failed with exit code 1: npm version 0.22.2 --userconfig HOT 2
- error on publishing HOT 1
- Publishing failed since update from [email protected] to [email protected] with files mentioned in .gitignore HOT 6
- Update a package.json in a sub folder
- CVE-2023-42282 HOT 1
- Support for custom package.json properties to write changelist entries
- NPM Audit Signatures issue on 11.0.3 HOT 2
- Failed step "prepare" of plugin "@semantic-release/npm" due to reading malformed path HOT 13
- semantic-release seems publishing twice and causing error. HOT 1
- Security Issue with out of date [email protected] found with SNYK HOT 3
- Array format/style is being changed HOT 3
- improve auth token resolution
- align approach for concatenating `.npmrc` files to better align with default npm behavior
- account for deprecation of `_auth` in existing `.npmrc` files
- Cannot set properties of null (setting 'peer') HOT 4
- npm ERR! log.http is not a function HOT 4
- [Question] monorepo project HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from npm.