When I run
npm install cypress --save-dev
In a Windows CMD Administrator session, I get the following output. This has been left overnight and still hangs on 0%:
If it's important, my current project dependencies are
"devDependencies": { "#types/react": "^17.0.0", "#types/react-dom": "^17.0.0", "#types/webpack": "^4.41.25", "#types/react-router-dom": "^5.1.7", "#types/mui-datatables": "^3.7.3", "#types/react-text-mask": "^5.4.7", "#typescript-eslint/eslint-plugin": "^4.17.0", "#typescript-eslint/parser": "^4.17.0", "clean-webpack-plugin": "^3.0.0", "css-loader": "^5.0.1", "eslint": "^7.21.0", "eslint-config-prettier": "^8.1.0", "eslint-plugin-react": "^7.22.0", "eslint-plugin-react-hooks": "^4.2.0", "eslint-webpack-plugin": "^2.5.2", "html-webpack-plugin": "^4.5.0", "husky": "^4.3.8", "lint-staged": "^10.5.4", "prettier": "2.2.1", "style-loader": "^2.0.0", "ts-loader": "^8.0.11", "typescript": "^4.1.2", "url-loader": "^4.1.1", "webpack": "^5.9.0", "webpack-cli": "^4.2.0", "webpack-dev-server": "^3.11.0", "webpack-merge": "^5.4.0" },
"dependencies": { "#date-io/dayjs": "^1.3.13", "#fontsource/roboto": "^4.2.2", "#material-ui/core": "^4.11.2", "#material-ui/icons": "^4.11.2", "#material-ui/lab": "^4.0.0-alpha.57", "#material-ui/pickers": "^3.3.10", "axios": "^0.21.1", "clsx": "^1.1.1", "dayjs": "^1.10.4", "emailjs-com": "^3.1.0", "jwt-decode": "^3.1.2", "moment-timezone": "^0.5.33", "mui-datatables": "^3.7.7", "notistack": "^1.0.9", "react": "^17.0.1", "react-dom": "^17.0.1", "react-live-clock": "^5.2.0", "react-moment": "^1.1.1", "react-print-components": "^1.0.4", "react-router-dom": "^5.2.0", "react-text-mask": "^5.4.3", "text-mask-addons": "^3.8.0" }
Any help to identify the cause or any logs I should be looking at would be greatly appreciated
I had the same issue when trying do a fresh npm installation for a project.
Running in the same command in an elevated window did not help.
Jakob's answer helped above:
Visit https://docs.cypress.io/guides/getting-started/installing-cypress#Direct-download
Download the version of Cypress from https://download.cypress.io/desktop
or alternatively put the version number at the end : https://download.cypress.io/desktop/8.7.0
Extract the folder to:
C:\Users\[username]\AppData\Local\Cypress\Cache\[version]
I ran npm install and the install completed without error.
Unzipping manually downloaded cypress to AppData/Local/Cypress/Cache/[version]/ fixed the issue for me.
After removing cypress from the AppData/Local and AppData/Roaming if you try to run npx cypress open you will see:
Cypress executable not found at: C:\Users\[user]\AppData\Local\Cypress\Cache\8.5.0\Cypress\Cypress.exe
So it worked after unzipping Cypress there manually.
I had this same issue and seemed to fix this issue by upgrading to the latest version of node and npm.
It seems like an issue that happened to me when I had a power outage during installation - so if I am right it occurs when an installation is forced down midway. I managed to solve it by deleting every cypress folder from AppData before running npm install cypress --save-dev .
Related
I am using Gatsby Plugin sharp with other plugins for remark images. Package json provided below.
Strangely the build goes through fine on MacOS but fails inside the Debian docker container while try to fetch metadata for a PNG image. This error is faced by gatsby-plugin-sharp
package.json - only dependencies included
"dependencies": {
"#buzz/as-components": "^1.0.3",
"#dx/continuum-footer": "^1.5.1",
"#marcom/ac-sasskit": "^7.3.0",
"gatsby": "^2.26.1",
"gatsby-plugin-emotion": "^5.2.0",
"gatsby-plugin-flexsearch": "^1.0.3",
"gatsby-plugin-manifest": "^2.6.1",
"gatsby-plugin-offline": "^3.4.0",
"gatsby-plugin-react-helmet": "^3.4.0",
"gatsby-plugin-sass": "^3.0.0",
"gatsby-plugin-sharp": "^2.14.1",
"gatsby-remark-autolink-headers": "^2.10.0",
"gatsby-remark-code-buttons": "^2.0.4",
"gatsby-remark-images-anywhere": "^1.3.0",
"gatsby-remark-prismjs": "^3.13.0",
"gatsby-source-filesystem": "^2.5.0",
"gatsby-transformer-remark": "^2.16.0",
"gatsby-transformer-sharp": "^2.12.0",
"prismjs": "^1.23.0",
"prop-types": "^15.7.2",
"react": "^16.13.1",
"react-dom": "^16.12.0",
"react-helmet": "^6.1.0",
"react-multilevel-sidebar": "^1.0.4",
"remark-grid-tables": "^2.1.1",
"sass": "^1.32.4"
},
"engines": {
"node": ">=15.0.0 <=15.8.0"
},
"devDependencies": {
"node-sass": "^5.0.0",
"prettier": "2.2.1"
}
Error that I face:
/app/src/blog/2019-02-19-gridsome-05/plugins.png
Error: Input file contains unsupported image format
There isn't much details available around the error - Any help would be appreciated. I feel like this could be a C library issue as Gatsby Plugin builds on the fly and leverages C/CPP libraries.
Ended up solving this - Leaving the cause of issue here so that it can help others -
I was using a NodeJS - 15.8.0-slim base image. Gatsby Plugin Sharp is dependent on C libraries and binaries behind the scenes which were not really included in the Slim base image. I used 15.8.0-buster image and it worked all good.
The log was extremely misleading and ended up wasting a lot of my time. Hope this saves the time of anyone else who ends up with this.
I have this new Ember project and I installed the google node sdk via npm install googleapis --save-dev. I then installed ember-cli-es6-transform in hopes of importing the es6 modules from the google api node client.
However I noticed in ./node_modules/googleapis there is a build/src folder instead of a src folder. In the Github repo, it's just a src folder. Why is this? This is causing my imports to be wonky while using ember-cli-es6-transform.
This is all that is in my devDependencies:
"devDependencies": {
"broccoli-asset-rev": "^2.4.5",
"ember-ajax": "^3.0.0",
"ember-cli": "~3.1.4",
"ember-cli-app-version": "^3.0.0",
"ember-cli-babel": "^6.6.0",
"ember-cli-dependency-checker": "^2.0.0",
"ember-cli-es6-transform": "^1.0.0",
"ember-cli-eslint": "^4.2.1",
"ember-cli-htmlbars": "^2.0.1",
"ember-cli-htmlbars-inline-precompile": "^1.0.0",
"ember-cli-inject-live-reload": "^1.4.1",
"ember-cli-qunit": "^4.1.1",
"ember-cli-sass": "^10.0.1",
"ember-cli-shims": "^1.2.0",
"ember-cli-sri": "^2.1.0",
"ember-cli-uglify": "^2.0.0",
"ember-data": "~3.1.0",
"ember-export-application-global": "^2.0.0",
"ember-load-initializers": "^1.0.0",
"ember-maybe-import-regenerator": "^0.1.6",
"ember-resolver": "^4.0.0",
"ember-source": "~3.1.0",
"ember-welcome-page": "^3.0.0",
"eslint-plugin-ember": "^5.0.0",
"googleapis": "^40.0.1",
"loader.js": "^4.2.3",
"sass": "^1.22.2"
},
npm does not require that a repository place its main file in any particular place or name it index.js. It is recommended that you look at a repo's package.json and use the path and file listed under the "main" key.
You can see it at https://github.com/googleapis/google-api-nodejs-client/blob/cb9326b902d6c203c498a2e269f256bcc3b23c2d/package.json#L42
googleapis chooses to build its source prior to putting it on npm to make it easier for us to use, hence the build/src directory.
For more information regarding the "main" key in package.json, see https://docs.npmjs.com/files/package.json#main
Note that ember-cli-es6-transform allows you to specify any path, so just put the correct path in as an argument.
app.import('node_modules/googleapis/build/src/index.js', {
using: [
{ transformation: 'es6', as: 'googleapis' }
]
});
I'm having a difficult time building a TypeScript application on Heroku.
My dependencies list includes a type definition for all of the packages I'm using:
"dependencies": {
"#nestjs/common": "^4.5.1",
"#nestjs/core": "^4.5.1",
"#nestjs/microservices": "^4.5.1",
"#nestjs/testing": "^4.5.1",
"#nestjs/websockets": "^4.5.1",
"#types/express": "^4.0.39",
"#types/jest": "^21.1.8",
"#types/json-schema": "^6.0.0",
"#types/jsonwebtoken": "^7.2.5",
"#types/mongoose": "^4.7.29",
"#types/node": "^8.5.1",
"#types/passport": "^0.4.2",
"#types/passport-jwt": "^3.0.0",
"#types/supertest": "^2.0.4",
"chalk": "^2.3.0",
"dotenv": "^4.0.0",
"express-jwt": "^5.3.0",
"global": "^4.3.2",
"jsonwebtoken": "^8.1.0",
"mongoose": "^4.13.7",
"passport": "^0.4.0",
"passport-jwt": "^3.0.1",
"redis": "^2.8.0",
"reflect-metadata": "^0.1.10",
"rxjs": "^5.5.5",
"tslint": "^5.8.0",
"ts-node": "^4.0.2",
"typescript": "^2.6.2"
},
However, when building on Heroku, I get:
error TS2688: Cannot find type definition file for 'node'
error TS2307: Cannot find module 'http'
and more. My tsconfig.json sets the typeRoots as './node_modules/#types' and I get a successful build locally.
Why can't Heroku find these types?
Apparently Heroku wasn't picking up changes to my package.json file or had cached some portion of the build process that was excluding #type definitions that I had moved from devDependencies to dependencies.
I cleared the build cache as such:
$ heroku plugins:install heroku-repo
$ heroku repo:purge_cache -a [appname]
$ git commit --allow-empty -m "Purge cache"
$ git push heroku master
and everything works as expected.
I am working on a Rails project that uses flexicious-react-datagrid and flexicious-react-datagrid-styles node modules. These modules are referenced in the package.json as:
"dependencies": {
...
"flexicious-react-datagrid": "file:./npm_libs/flexicious-react-datagrid",
"flexicious-react-datagrid-styles": "^1.2.0",
...
}
The problem I have is manually updating one of the modules to a licensed version.
The public flexicious-react-datagrid module is a trial version, which after some amount of time working with it, it has now expired and gives a popup with ErrorCode103 when trying to load the page and some infinite loop runs so the page becomes stuck loading forever.
The Flexicious team provides the licensed version by providing a react-datagrid.min.js file that contains the licensed code. Even though I replace this in the node module, The error still occurs.
This makes it seem like it's caching the old code server-side, since the code that would invoke the ErrorCode103 popup should be from the code that was replaced. I've tried loading in incognito or other browsers with no luck.
Our project uses browserify, and I have some suspicion (but not sure) that this may be what is caching the module. I haven't had any luck trying to find what is causing this issue so far.
My package.json:
{
"name": "redacted",
"version": "0.0.1",
"description": "redacted",
"author": "redacted",
"license": "SEE LICENSE IN LICENSE.TXT",
"babel": {
"comments": false,
"presets": [
"es2015",
"react"
]
},
"devDependencies": {
"browserify": "~> 14.0.0",
"browserify-incremental": "^3.1.0",
"browserify-css": "0.10.0"
},
"dependencies": {
"babel-core": "^6.0.0",
"babel-eslint": "^6.0.4",
"babel-loader": "^6.0.0",
"babel-polyfill": "^6.3.14",
"babel-preset-es2015": "^6.0.15",
"babel-preset-react": "^6.0.15",
"babelify": "^7.2.0",
"bower-webpack-plugin": "^0.1.9",
"codemirror": "^5.22.0",
"copy-webpack-plugin": "^4.0.1",
"copyfiles": "^0.2.1",
"core-js": "^2.4.0",
"css-loader": "^0.23.0",
"eslint": "^2.0.0",
"eslint-loader": "^1.0.0",
"eslint-plugin-react": "^5.1.1",
"file-loader": "^0.8.4",
"flexicious-react-datagrid": "file:./npm_libs/flexicious-react-datagrid",
"flexicious-react-datagrid-styles": "^1.2.0",
"gh-pages-deploy": "^0.4.0",
"glob": "^7.0.0",
"history": "^2.1.1",
"isparta-instrumenter-loader": "^1.0.0",
"jquery-browserify": "*",
"material-ui": "^0.16.5",
"minimist": "^1.2.0",
"mocha": "^2.2.5",
"moment": "^2.17.1",
"node-sass": "^3.4.2",
"normalize.css": "^4.1.1",
"null-loader": "^0.1.1",
"open": "0.0.5",
"postcss": "^5.0.11",
"postcss-loader": "^0.9.1",
"react": "^15.4.0",
"react-addons-test-utils": "^15.4.0",
"react-codemirror": "^0.3.0",
"react-day-picker": "^5.0.0",
"react-dom": "^15.4.0",
"react-router": "^2.4.0",
"react-tap-event-plugin": "^2.0.0",
"recursive-readdir-sync": "^1.0.6",
"rimraf": "^2.4.3",
"sass-loader": "^3.1.2",
"style-loader": "^0.13.0",
"url-loader": "^0.5.6"
}
}
flexicious-react-datagrid was version 1.1.6, it installs 1.3.8 which is the version I have my licensed code in within ./npm_libs/flexicious-react-datagrid.
Even not using the licensed code, 1.3.8 isn't being loaded as it is still giving me an error of an expired trial.
It was Browserify after all. I finally stumbled upon the cached version, it was hiding in a /tmp/ folder in the project's root directory.
I likely also blinded myself by having the Gitignored package in Sublime installed, which didn't show or search files/folders that were in the .gitignore file. I had to remove that package and edit my "folder_exclude_patterns" in my sublime-settings to re-show these folders.
I've included removing the tmp folder in its entirety to part of our build procedure so we don't have this issue again.
Yep, it looks as if you're still using a previously installed version of flexicious-react-datagrid.
The first guess is that you need to run npm install ./npm_libs/flexicious-react-datagrid to update this module. npm manager usually copies all dependency modules into node_modules dir and then node.js uses it to resolve require('flexicious-react-datagrid').
So I have an application that pulls in some dependencies. I have figured out how to lock those down quite easily and thus my Package.json looks like so:
"webpack": "2.2.1",
Great! So webpack is locked to that version, but I have noticed something in webpacks package.json. They don't lockdown their dependencies:
"dependencies": {
"acorn": "^4.0.4",
"acorn-dynamic-import": "^2.0.0",
"ajv": "^4.7.0",
"ajv-keywords": "^1.1.1",
"async": "^2.1.2",
"enhanced-resolve": "^3.0.0",
"interpret": "^1.0.0",
"json-loader": "^0.5.4",
"loader-runner": "^2.3.0",
"loader-utils": "^0.2.16",
"memory-fs": "~0.4.1",
"mkdirp": "~0.5.0",
"node-libs-browser": "^2.0.0",
"source-map": "^0.5.3",
"supports-color": "^3.1.0",
"tapable": "~0.2.5",
"uglify-js": "^2.8.5",
"watchpack": "^1.2.0",
"webpack-sources": "^0.2.0",
"yargs": "^6.0.0"
},
So the other day our app spun up on a container and grabbed webpack 2.2.1 like it should have, but grabbed the latest uglify-js which caused issues with our production app.
Is there anyway to enforce versions for dependencies that our dependencies are utilizing?
npm shrinkwrap is what I was looking for and needing.