I am trying to run the packaged electron app on my local Mac. But get an error message saying Error: Cannot find module ... I think the node_module is not installed.
I used electron-forge package to build the package.
Is there something wrong with my webpack config?
https://github.com/zhex900/mir-kiosk-electron/blob/master/electron-kiosk/webpack.main.config.js
#package.json
"dependencies": {
"#aws-sdk/client-iot": "^3.14.0",
"#aws-sdk/client-s3": "^3.14.0",
"#aws-sdk/s3-request-presigner": "^3.14.0",
"aws-iot-device-sdk-v2": "^1.4.5",
"babel-runtime": "^6.26.0",
"electron-squirrel-startup": "^1.0.0",
"macaddress": "^0.5.2",
"react": "^17.0.2",
"react-dom": "^17.0.2"
}
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'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've made a web app using create-react-app which works fine, and I usually run it using npm start but now I have to deploy it and make it work with nodejs forever module.
If I do node src/index.js it will give a syntax error and to fix this I used babel to transpile es6 to es5, but again I get the following syntax error when importing the css file:
/client/src/stylesheets/menu.css:1
(function (exports, require, module, __filename, __dirname) { header {
^
SyntaxError: Unexpected token {
This is my package.json file:
{
"dependencies": {
"async": "^2.5.0",
"axios": "^0.16.2",
"classnames": "^2.2.5",
"date-diff": "^0.1.3",
"jwt-decode": "^2.2.0",
"lodash": "^4.17.4",
"react": "^15.6.1",
"react-bootstrap": "^0.31.2",
"react-bootstrap-table": "^4.0.2",
"react-dom": "^15.6.1",
"react-redux": "^5.0.6",
"react-router": "^4.2.0",
"react-router-dom": "^4.2.2",
"react-scripts": "1.0.12",
"react-select": "^1.0.0-rc.5",
"redux": "^3.7.2",
"redux-thunk": "^2.2.0",
"shortid": "^2.2.8",
"validator": "^8.1.0"
},
"scripts": {
"start": "react-scripts-with-stylus start src/stylesheets/menu.styl",
"build": "react-scripts-with-stylus build src/stylesheets/menu.styl",
"test": "react-scripts test --env=jsdom",
"eject": "react-scripts eject"
},
"proxy": "http://localhost:8081",
"devDependencies": {
"babel": "^6.23.0",
"babel-cli": "^6.24.1",
"babel-core": "^6.25.0",
"babel-polyfill": "^6.23.0",
"babel-preset-es2015": "^6.24.1",
"babel-preset-stage-0": "^6.24.1",
"create-react-app-stylus": "^1.1.1",
"webpack": "^3.5.5"
}
}
To sum up the answer to this question:
If you need to deploy it, you should make a build, not run your application directly.
run npm run build and it will generate build files into a new folder.
You should not try to run the application with npm at all. You should copy all the files from the build folder into the root of your server and when a user opens the page it will be shown index.html file.
If your code has changed and is ready for production you can rebuild it, or you can automate this process with some CI tool.
You should only have React client files on your Git repository, build files should be generated during the build process on your server.
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').
noob question regarding Node and npm: I have a package.json file with a list of dependancies that I want to install with npm install. When I run the command, nothing happens, I don't even receive an error, nothing at all :(
But if I try to install a single package from the list, it works perfectly...
I haven't created the package.json myself, so I am not sure what the "proxyURL" thing does...
{
"name": "dss",
"version": "0.0.0",
"repository": {
"type": "git",
"url": "*urlofmyrepo*"
},
"dependencies": {
"bower": "^1.7.7",
"cssmin": "^0.4.3",
"gulp": "^3.9.0",
"gulp-batch": "^1.0.5",
"gulp-concat": "^2.6.0",
"gulp-if": "^2.0.0",
"gulp-jshint": "^2.0.0",
"gulp-rename": "^1.2.2",
"gulp-sass": "^2.2.0",
"gulp-sourcemaps": "^1.6.0",
"gulp-strip-debug": "^1.1.0",
"gulp-uglify": "^1.5.1",
"gulp-util": "^3.0.7",
"gulp-watch": "^4.3.5",
"jshint": "^2.9.1",
"lodash": "^4.2.1",
"minimatch": "^3.0.0",
"sass": "^0.5.0",
"uglifyjs": "^2.4.10",
"underscore": "^1.8.3",
"yuglify": "^0.1.4"
},
"private": true,
"APIMethod": "stub",
"proxyURL": "http://localhost:8000",
"devDependencies": {}
}
Any clue?
Thank you
Rename/remove your package.json file.
Create a new package file by running:
npm init
Option A: Copy the dependencies you need into the newly created package.json.
Option B: Install the packages and use --save to add the packages to the package.json file.
Run npm install to install the dependencies.
just ran into this.
in my case the answer was environment variable NODE_ENV was set to 'production'
I haven't looked it up but when I changed it to something else, it started working.
I was testing this environment variable for something else and didn't realize it had this effect also.
For me it was a bad version value. Changing from 3.0 to 3.0.0 results in proper installation. 3.0 generates a warning, but fails to do the installation (ie it should be an error).