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').
Related
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 .
I have a working production Firebase Node server that I have working locally. My UAT version does not work locally, it times out trying to access my Firebase documents (Error: 4 DEADLINE_EXCEEDED: Deadline exceeded). After working through this issue after the original posting here it looks like the node_modules folder that I created originally, with the configuration below will allow local connection, but any upgrade or modification does not work. The second configuration is an example of this. In other words if I copy the node_modules folder to another directory that has my source code, then run
firebase serve
it works, but if I run npm update, then I time out trying to access Firebase DB documents.
"#google-cloud/storage": "^3.0.4",
"actions-on-google": "^2.10.0",
"axios": "^0.19.0",
"fast-xml-parser": "^3.12.20",
"firebase-admin": "^8.0.0",
"firebase-client": "0.1.1",
"firebase-functions": "^3.0.2",
"moment": "^2.24.0",
"request-promise-native": "^1.0.7",
"sprintf-js": "^1.1.2",
"stream-buffers": "^3.0.2",
"twilio": "^3.32.0"
},
"dependencies": {
"#google-cloud/storage": "^3.0.4",
"actions-on-google": "^2.10.0",
"axios": "^0.19.0",
"fast-xml-parser": "^3.12.20",
"firebase-admin": "8.0.0",
"firebase-client": "0.1.1",
"firebase-functions": "3.0.2",
"moment": "^2.24.0",
"request-promise-native": "^1.0.7",
"sprintf-js": "^1.1.2",
"stream-buffers": "^3.0.2",
"twilio": "^3.32.0"
},
I attempted to upgrade one dependency at a time, starting with firebase-functions, and that upgraded my firebase-admin to 8.9.0, so I'm sort of assuming it's firebase-admin though I suppose it could be firebase-functions.
In either case I'd like to be up-to-date, but being able to test locally is critical.
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.
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.