I have a repository that is showing npm security advisories from dependabot, even though I only have the "pip" ecosystem configured:
version: 2
updates:
- package-ecosystem: "pip"
directory: "/src/" # Location of package manifests
schedule:
interval: "weekly"
My npm packages are only used at build time, and not deployed. But looks like dependabot sees them because they are in the src/static directory.
I haven't found documentation on this particular issue.
Has anyone found the same situation? How did you solve it?
Related
I have the Dependabot GitHub action enabled in my React Native app's repository but for some reason, it won't automatically update. I have 2 dependencies that won't:
xmldon 0.5.0 and node-fetch 2.6.1
I keep getting this error when I try to Create Dependabot security update:
Dependabot failed to update your dependencies because there was an error parsing the package.json found at /package.json.
Dependabot encountered the following error:
Dependabot::DependencyFileNotParseable
Also, I shouldn't have to manually create a dependabot security updates since my github action should automate it, which looks like this:
# To get started with Dependabot version updates, you'll need to specify which
# package ecosystems to update and where the package manifests are located.
# Please see the documentation for all configuration options:
# https://help.github.com/github/administering-a-repository/configuration-options-for-dependency-updates
version: 2
updates:
# Maintain dependencies for GitHub Actions
- package-ecosystem: "github-actions"
directory: "/"
schedule:
interval: "weekly"
# Maintain dependencies for npm
- package-ecosystem: "npm"
directory: "/"
schedule:
interval: "weekly"
# Maintain dependencies for Python files in requirements.txt
- package-ecosystem: "pip"
directory: "/"
schedule:
interval: "weekly"
Route: my-app/.github/dependabot.yml
Am I missing something here? I enabled this the exact same way for my website, which is written in React.js, and it's working perfectly.
I'm trying to install electron using both npm(npm install electron) and yarn but stuck into a bottleneck issue. PFB the error msg
Error: self signed certificate in certificate chain
at TLSSocket.onConnectSecure (_tls_wrap.js:1473:34)
at TLSSocket.emit (events.js:311:20)
at TLSSocket._finishInit (_tls_wrap.js:916:8)
at TLSWrap.ssl.onhandshakedone (_tls_wrap.js:686:12) {
code: 'SELF_SIGNED_CERT_IN_CHAIN'
}
So, in order to bypass ssl I ran the command npm config set strict-ssl=false and tried again.
Butr now, I get a new error.
ChecksumMismatchError: Generated checksum for
"electron-v5.0.13-darwin-x64.zip" did not match expected checksum.
PFB the versions I'm using.
Node - v12.16.1
npm - 6.13.4
OS - macOS mojave 10.14.16
I struggled with self-signed certificates on an enterprise network too and this is what helps in my case. Whenever I want to install a version of electron, I download the electron-vX.Y.Z-win32-x64.zip and place it in electrons local cache folder. Which is %APP_DATA%\Local\electron\Cache on windows systems.
After that I run a normal npm install. It will look for a cached zip file, find one and use that.
The cache locations for the other operating systems can be found here:
https://www.electronjs.org/docs/tutorial/installation#cache
Edit:
Respondong to your comment - there are a couple of old entries on the electron issue tracker on github, search that for 'ChecksumMismatchError', it hints for mismatching versions of electron, node and maybe other dependencies. One solution would be to calculate the checksum of the zip (assuming, you got it from a trusted source!!) and update the package-lock.json (or yarn). Or - upgrade to the latest version of electron. That's what I recommend, then you get the latest and safest chromium.
https://github.com/electron/electron/issues/13168#issuecomment-400079161
Found the solution. It was the firewall's issue. Temporarily disabled it to proceed with the installation.
I am on different servers and run npm install
One server is ok. Another failed showing below error:
no matching version found for es-abstract#1.14.0
I tried npm ci. Same deal.
Then I did npm install es-abstract-1.14.0.tgz
But the size node_modules/ are different. I am using du -shc --apparent-size node_modules/ to ignore the sparse files within the folder. Why?
Could I accept that this is the network issue of the failed server？ And just keep doing this? I mean, is the installation still going to be ok in this way?
At the time that this answer was written, there are 33 release versions for es-abstract on github, but only 32 release versions are listed on its npm registry. The missing version in the registry is 1.14.0.
Perhaps on one of your servers, you had this package cached (maybe it was previously listed on the NPM registry?, or maybe from downloading it from github?), and on the other server you did not have this package cached.
I had this same error message when trying to npm install a project from github.
In my situation, the es-abstract package was not explicitly listed in the package.json file, but it was a dependency of another package. Therefore I explicitly added it with the next highest version listed on the registry, and it worked.
e.g.
"dependencies": {
"es-abstract": "1.14.1",
...
Just a guess, but maybe 1.14.0 used to be listed on the registry, but now it's not?
I have configured a private agent in VSTS and have installed NPM there globally. When I'm trying to install NPM through my build task, it is still installing NPM packages for every build which is taking an aweful lot of time- approximately 12 minutes.
How can I cache the NPM installations so that the build time is reduced?
We use npm-cache, npm-cache is a node module that will calculate a hash of your package.json file for every hash it will create zip folder on your build server with the content of node_modules, now npm install is reduced to extracting a zip on every build (of course only in case you didn’t actually change package.json).
The idea is: in the first time the tool download the npm packages and save them locally, in the second time if the package.json not changed he takes the packages from the local disk and copy them to the build agent folder, only if the package.json changed he downloads the packages from the internet.
Install the npm-cache on the build machine:
npm install npm-cache -g
In the build definition add Command Line task (Tool: C:\Windows\User\AppData\Roaming\npm\npm-cache (or just npm-cache if you add the tool to environment path variables); Arguments:install npm; Working folder: $(Build.SourcesDirectory) (or where package.json located).
MS has finally implemented this feature (currently in beta) https://learn.microsoft.com/en-us/azure/devops/pipelines/caching/index?view=azure-devops#nodejsnpm
From there:
variables:
npm_config_cache: $(Pipeline.Workspace)/.npm
steps:
- task: CacheBeta#0
inputs:
key: $(Build.SourcesDirectory)/package-lock.json
path: $(npm_config_cache)
displayName: Cache npm
- script: npm ci
Unfortunately we cannot cache the NPM installations as no such a built-in feature for now.
However there's already a user voice submitted to suggest the feature : Improve hosted build agent performance with build caches, and seems the VSTS team are actively working on this now...
For now, you can try to speed Up NPM INSTALL on Visual Studio Team Services
Use Cache task
Caching is added to a pipeline using the Cache pipeline task. This
task works like any other task and is added to the steps section of a
job
With the following configuration:
pool:
name: Azure Pipelines
steps:
- task: Cache#2
inputs:
key: 'YOUR_WEB_DIR/package.json'
path: 'YOUR_WEB_DIR/node_modules/'
- task: Npm#1
inputs:
command: 'install'
workingDir: 'YOUR_WEB_DIR/frontend'
You can use key YOUR_WEB_DIR/package-lock.json too, but be aware that file might be changed by other next step like npm install so hash also will be changed.
Our developers pull all of their npm dependencies via an artifactory proxy. The artifactory setup uses a virtual repository that consists of a local npm repository and a remote npm repository.
When developers perform an npm install, the process is slow and often hangs at
fetchMetadata -> network
Any ideas on tracing the source of this issue?
Does artifactory provide a 'trace' api for npm resources, similar to what they have for maven dependencies here maven trace?
Would re-indexing the virtual repository on artifactory help?
Struggled with the same thing. By adding the debug flag when running install helped me. I don't know why, might be some race condition or to many half open connections or something else. When the debug flag is added each step takes a fraction of a second longer to complete, and that seems to be enough. Here's an example for a local package:
npm install -d
or a longer example:
sudo npm install -g -ddd eslint-cli
The number of d's tells npm how verbose debug you want. More d's means more info and longer time to execute. One d did it for me, but my laptop is slow to begin with.