Electron Forge v6, Keytar & Node-Loader Error "no suitable image found... file too short" - node.js

I am having some trouble getting the Keytar package working in an Electron Forge v6 project (beta.54).
In a freshly generated project, I receive an error about "file too short" when I run the application. Below is an excerpt of the error dialog shown originating from the main process:
> electron-forge start
✔ Checking your system
✔ Locating Application
✔ Preparing native dependencies: 1 / 1
✔ Compiling Main Process Code
✔ Launch Dev Servers
✔ Compiling Preload Scripts
✔ Launching Application
Webpack Output Available: http://localhost:9000
App threw an error during load
Error: node-loader:
Error: dlopen(/Users/abc/Desktop/app2/.webpack/main/9e6f9bf6669542cb15efba32c033f3de.node, 1): no suitable image found. Did find:
/Users/abc/Desktop/app2/.webpack/main/9e6f9bf6669542cb15efba32c033f3de.node: file too short
/Users/abc/Desktop/app2/.webpack/main/9e6f9bf6669542cb15efba32c033f3de.node: file too short
at Object.<anonymous> (/Users/abc/Desktop/app2/.webpack/main/index.js:1015:9)
at Object../node_modules/keytar/build/Release/keytar.node (/Users/abc/Desktop/app2/.webpack/main/index.js:1018:30)
at __webpack_require__ (/Users/abc/Desktop/app2/.webpack/main/index.js:21:30)
at Object../node_modules/keytar/lib/keytar.js (/Users/abc/Desktop/app2/.webpack/main/index.js:1029:14)
at __webpack_require__ (/Users/abc/Desktop/app2/.webpack/main/index.js:21:30)
at Object../src/index.ts (/Users/abc/Desktop/app2/.webpack/main/index.js:1440:14)
at __webpack_require__ (/Users/abc/Desktop/app2/.webpack/main/index.js:21:30)
at /Users/abc/Desktop/app2/.webpack/main/index.js:85:18
at Object.<anonymous> (/Users/abc/Desktop/app2/.webpack/main/index.js:88:10)
at Module._compile (internal/modules/cjs/loader.js:1152:30)
It seems that node-loader is having trouble with this package. I cannot decipher what is happening as I can see the package .node files are copied into ./webpack/main/native_modules , but there is a hashed filename at the root which seems to import the native file.
One strange thing I did notice is that the hashed file at .webpack/main/9e6f9bf6669542cb15efba32c033f3de.node contains the following and not the native binary data:
module.exports = __non_webpack_require__("./native_modules/build/Release/keytar.node")
Subsequently... these .node files /native_modules/build/Release/keytar.node are what I expect.
How should one proceed? I didn't rush to open issues on GitHub until I figured where the issue was coming from.
I feel at the root, there's an issue with how the .node file is generated in keytar, but then who even knows what black magic is happening with Webpack and the loaders.
Steps to reproduce
Create a new Electron Forge project `npx create-electron-app app2 --template=typescript-webpack
Install Keytar npm install keytar
Add const key tar = require('keytar'); into src/index.ts
Run the app via npm run start
Experience the error
Versions
Node: v14.14.0
NPM: v7.0.13
Package JSON dependencies:
"devDependencies": {
"#electron-forge/cli": "^6.0.0-beta.54",
"#electron-forge/maker-deb": "^6.0.0-beta.54",
"#electron-forge/maker-rpm": "^6.0.0-beta.54",
"#electron-forge/maker-squirrel": "^6.0.0-beta.54",
"#electron-forge/maker-zip": "^6.0.0-beta.54",
"#electron-forge/plugin-webpack": "6.0.0-beta.54",
"#marshallofsound/webpack-asset-relocator-loader": "^0.5.0",
"#typescript-eslint/eslint-plugin": "^4.0.1",
"#typescript-eslint/parser": "^4.0.1",
"css-loader": "^4.2.1",
"electron": "11.0.3",
"eslint": "^7.6.0",
"eslint-plugin-import": "^2.20.0",
"fork-ts-checker-webpack-plugin": "^5.0.14",
"node-loader": "^1.0.1",
"style-loader": "^1.2.1",
"ts-loader": "^8.0.2",
"typescript": "^4.0.2"
},
"dependencies": {
"electron-squirrel-startup": "^1.0.0",
"keytar": "^7.2.0"
}

I had pretty much exact replica of this issue with native module loading the only difference being that in my case the module was locally built and installed as a part of the project.
Something in the webpack's support for native modules has issues within this configuration and causes this. What did the trick for me was to remove node-loader in webpack in webpack.rules.js, ie removing this section:
- // Add support for native node modules
- {
- test: /\.node$/,
- use: 'node-loader',
- },
I found this solution and further discussion on the topic from the issue tracker of electron-forge: https://github.com/electron-userland/electron-forge/issues/1688

Related

babel-node doesn't transpile JSX in npm react script for Node version 14

I'm having a big problem with running my npm script using babel-node. This script generates static error pages from react components. With Node versions 10 and 12 it is running successfully, but when I have updated my node version to 14 babel-node seems to stop transpiling JSX. Now I get this error:
<MuiThemeProvider theme={theme}>
^
SyntaxError: Unexpected token '<'
at Loader.moduleStrategy (internal/modules/esm/translators.js:140:18)
at async link (internal/modules/esm/module_job.js:42:21)
My devDependencies in package.json file:
"devDependencies": {
"#babel/node": "^7.14.2",
"#babel/preset-env": "^7.14.2",
"babel-plugin-styled-components": "^1.12.0",
"prettier": "2.3.0"
}
and script in package.json:
"generate-error-pages": "babel-node scripts/generate-error-pages.js"
And this is my .babelrc file:
{
"presets": ["#babel/preset-env", "#babel/react"],
"plugins": [["styled-components", { "ssr": true }]]
}
I can't make it work with Node version 14 like it worked with version 10 and 12.
Creating new repository helped me find the problem. In previous versions of Node I had to add
"type": "module"
in package.json because without it there was an exception caused by using import in JS script. Now I observed that in Node 14 I don't need "type": "module" anymore. This was even the problem of described exception. After deleting this from package.json it is now working also in Node 14.

React native : Failed to construct transformer: Error: Cannot create a string longer than 0x1fffffe8 characters

package.json
{
"name": "project",
"version": "0.0.1",
"private": true,
"scripts": {
"android": "react-native run-android",
"ios": "react-native run-ios",
"start": "react-native start",
"test": "jest",
"lint": "eslint ."
},
"dependencies": {
"#react-native-community/async-storage": "^1.12.0",
"#react-native-community/clipboard": "^1.2.3",
"#react-native-community/masked-view": "^0.1.10",
"#react-navigation/drawer": "^5.9.0",
"#react-navigation/native": "^5.7.3",
"#react-navigation/stack": "^5.9.0",
"#twotalltotems/react-native-otp-input": "^1.3.11",
"jetifier": "^1.6.6",
"react": "16.13.1",
"react-native": "^0.63.2",
"react-native-barcode-builder": "^2.0.0",
"react-native-biometrics": "^2.1.4",
"react-native-chart-kit": "^6.6.1",
"react-native-gesture-handler": "^1.7.0",
"react-native-image-picker": "^2.3.3",
"react-native-localization": "^2.1.6",
"react-native-paper": "^4.0.1",
"react-native-reanimated": "^1.13.0",
"react-native-safe-area-context": "^3.1.6",
"react-native-screens": "^2.10.1",
"react-native-splash-screen": "^3.2.0",
"react-native-svg": "^12.1.0",
"react-native-swipe-list-view": "^3.2.3",
"react-native-vector-icons": "^7.0.0"
},
"devDependencies": {
"#babel/core": "7.11.4",
"#babel/runtime": "7.11.2",
"#react-native-community/eslint-config": "1.1.0",
"babel-jest": "25.5.1",
"eslint": "6.8.0",
"jest": "25.5.4",
"metro-react-native-babel-preset": "0.59.0",
"miragejs": "^0.1.40",
"react-test-renderer": "16.13.1"
},
"jest": {
"preset": "react-native"
}
}
i did't fonund any answers related this except this : https://github.com/facebook/react-native/issues/28189
but it won't work for me...
myapp successfully install on android emulator but stuck at splash screen ...
the app works fine in my office computer but it did't work on my own computer
my node version : v14.10.0
so please help me.
I've tried to log the file that causing the error, but console.log wasn't working.
I come up with a quick hack to throw filePath then I've saw that a zip file, that I keeped as a backup, was the issue.
For some way react doesn't liked it so I have to move it outside of the project folder
For others having the same problem, and looking for a way to debug:
Edit /node_modules/jest-haste-map/build/worker.js
Wrap readFileSync in a try...catch, like this:
const getContent = () => {
if (content === undefined) {
try {
content = fs().readFileSync(filePath, 'utf8');
} catch (err) {
throw new Error(`error readFileSync ${filePath} : ${err.message}`);
}
}
return content;
};
(re)start metro bundler:
/node_modules/react-native/scripts/launchPackager.command; exit
My output:
To reload the app press "r"
To open developer menu press "d"
Failed to construct transformer: Error: error readFileSync <my project path>/some/big/file/that/caused/error : Cannot create a string longer than 0x1fffffe8 characters
at getContent (<my project path>/node_modules/jest-haste-map/build/worker.js:133:15)
at Object.worker (<my project path>/node_modules/jest-haste-map/build/worker.js:162:23)
at execFunction (<my project path>/node_modules/jest-worker/build/workers/processChild.js:145:17)
at execHelper (<my project path>/node_modules/jest-worker/build/workers/processChild.js:124:5)
at execMethod (<my project path>/node_modules/jest-worker/build/workers/processChild.js:128:5)
at process.messageListener (<my project path>/node_modules/jest-worker/build/workers/processChild.js:46:7)
at process.emi
Hope this helps others having the same problem!
I was running into the same problem.
warning: the transform cache was reset.
Welcome to React Native!
Learn once, write anywhere
Failed to construct transformer: Error: Cannot create a string longer than 0x1fffffe8 characters
at Object.slice (buffer.js:608:37)
at Buffer.toString (buffer.js:805:14)
at Object.readFileSync (fs.js:421:41)
at getContent (J:\expoProjects\rn-cnn\node_modules\metro\node_modules\jest-haste-map\build\worker.js:149:41)
at Object.<anonymous> (J:\expoProjects\rn-cnn\node_modules\metro\node_modules\jest-haste-map\build\worker.js:
199:9)
at Generator.next (<anonymous>)
at asyncGeneratorStep (J:\expoProjects\rn-cnn\node_modules\metro\node_modules\jest-haste-map\build\worker.js:
78:24)
at _next (J:\expoProjects\rn-cnn\node_modules\metro\node_modules\jest-haste-map\build\worker.js:98:9)
at J:\expoProjects\rn-cnn\node_modules\metro\node_modules\jest-haste-map\build\worker.js:103:7
at new Promise (<anonymous>) {
type: 'Error',
code: 'ERR_STRING_TOO_LONG'
I solved the error by changing the node version to v14+ and then reverting back to the old version of node v10.15.3.
I've run into the exact same error. Turns out it was an auto-generated big file from gradle (> 700MB) inside "android.gradle\6.0.1\executionHistory"
To figure out what file caused an error I used #dirk approach.
I don't sure why but my App_name.app.dSYM.zip became too large (536MB) so the node was unable to read it because of the 512MB limitation. It might be some different file in your case.
Here is a patch-package to get more information about the file which caused this error
diff --git a/node_modules/jest-haste-map/build/worker.js b/node_modules/jest-haste-map/build/worker.js
index 1996d4a..1f17f11 100644
--- a/node_modules/jest-haste-map/build/worker.js
+++ b/node_modules/jest-haste-map/build/worker.js
## -146,7 +146,11 ## function _worker() {
const getContent = () => {
if (content === undefined) {
- content = _gracefulFs().default.readFileSync(filePath, 'utf8');
+ try {
+ content = _gracefulFs().default.readFileSync(filePath, 'utf8');
+ } catch (err) {
+ throw new Error(`error readFileSync ${filePath} : ${err.message}`);
+ }
}
return content;
Make sure you don't have any large files in your root project including (mp4, images, .zip, etc)?
In my own case I noticed I was using an mp4 video file for my react native application which was too large in size. I had to delete it and that was the fix for me
It took me the whole day but I solved it. I still can't understand why I'm getting this error when I want to launch the app on iOS but:
removing the build directory in android/app fixed it.
Check if there any unrelated file or zip in your project structure/folder
if yes then delete file and error will be resolved
In my case there was a zip file of whole project in the project directory which cause the issue when I remove it from the project directory and run
npm start --reset cache
it worked for me.
I had similar issue. After some debugging I found that it crashes because of asset file, which was generated by android build previously.
I don't know why it is trying to import this file (I experience this issue on ios), but when I removed folder ./android/app/build it started working.
Even if issue is not related to this dir in your case, you need to find which asset caused this issue.
Moving any large asset files [pictures,videos,etc...] up out of the project directory.
https://github.com/facebook/react-native/issues/28189#issuecomment-592918995
I got this error when i run build.
But This fix worked for me.
I deleted a zip file at the root of my app (I compressed the whole project to zip at end of the previous day for backup)
And i stopped the server with ctr + c command
Then restarted the server with npx react-native start
All now works fine after restarting the server and without having to run build again.
Just delete any zipped file in your project root directory. In my case I had packaged the app and sent it to someone and forgot to remove the zipped file thereafter.
This answer helped me a lot https://stackoverflow.com/a/41963217/2915928
For my case my app had a lot of audio files being included in android app bundle, this was then creating a large zip file in android/build/intermediates. So rather than deleting the build folder this tell the packager to ignore the file causing the issue.
Here is an example of my fix replace asset_pack_bundle with whatever file or directory you are having an issue with.
const exclusionList = require('metro-config/src/defaults/exclusionList');
module.exports = {
transformer: {
getTransformOptions: async () => ({
transform: {
experimentalImportSupport: false,
inlineRequires: true,
},
}),
},
resolver: {
blacklistRE: exclusionList([/asset_pack_bundle\/.*/]),
},
};
I have followed the below steps and it worked for me:
1. cleared cache and unnecessary space from my mac.
2. cleared npm cache and watchman.
3. cleared gradle.
4. restarted the metro server.

Using external babel configuration breaks node/react app - internal server error

Does anyone have any clue why a babel config file would be loaded on npm run dev and why it would start flagging perfectly fine parts of my code?
I have a feeling it has something to do with Next.js. My package.json (that Im testing with) for reference:
},
"devDependencies": {
"#babel/preset-env": "^7.4.5",
"#babel/preset-react": "^7.0.0",
"#svgr/cli": "^4.2.0",
"babel-jest": "^24.8.0",
"babel-preset-stage-2": "^6.24.1",
"jest": "^24.8.0",
"nodemon": "^1.19.1"
}
My goal is to have an app that runs both npm run dev and npm test and not one or the other. At the moment, if I remove all my babel config files (needed to run jest), my web app will boot up perfectly fine. And vice versa. Honestly I don't think I need or want any babel config files to be active when I start running the server, but I need them to run jest.
So... either there is a way to disable babel from certain package.json scripts or otherwise get jest tests to work without breaking the core functionality of the app?
edit-i fixed it
//.babelrc
{
"presets": [
[
"next/babel"
]
]
}

react-geosuggest issue Module not found: Error: Can't resolve 'prop-types'

I'm having trouble releasing my application on Azure when it comes to use webpack.
The following error is thrown when run on the server.
ERROR in ./node_modules/react-geosuggest/module/prop-types.js
Module not found: Error: Can't resolve 'prop-types' in 'd:\a\1\s\some\project\node_modules\react-geosuggest\module'
# ./node_modules/react-geosuggest/module/prop-types.js 7:17-38
# ./node_modules/react-geosuggest/module/Geosuggest.js
# multi moment react-geosuggest react-bootstrap react-overlays ./Scripts/React/Components/Oem
and I don't see/know what exactly the issue is.
On the other hand - locally - it's running/building without any issues. So I'm really stuck at this point.
This is what my dependencies (in package.json) look like:
"dependencies": {
"bootstrap": "3.3.7",
"classnames": "^2.2.5",
"moment": "^2.19.2",
"react": "15.6.1",
"react-addons-css-transition-group": "^15.6.0",
"react-addons-transition-group": "^15.6.0",
"react-dom": "15.6.1",
"react-bootstrap": "0.31.5",
"react-geosuggest": "2.7.0",
"webpack": "^3.6.0",
"pathval": "1.1.0"
}
In antoher project where I use react-geosuggest it's working/building without any complains.
I've already tried to use the latest version of react & react-dom as well as adding prop-types. But still the same issue.
I had a similar problem and solved it by adding this to my dependencies section in package.json:
"prop-types": "^15.6.1"
followed by rerunning:
yarn install

Warnings when building backend Express/WS Node app with Webpack

I am getting some confusing warnings when building a backend Node server with Webpack. I want to use Webpack to build my backend primarily for two reasons:
Webpack creates a single executable file, which is easier to deploy
Webpack includes all of my app's dependencies, so I can deploy my app to any compatible Node environment without needing to install dependencies first
Here are the warnings I'm getting:
WARNING in ./~/ws/lib/BufferUtil.js
Module not found: Error: Can't resolve 'bufferutil' in .../node_modules/ws/lib
# ./~/ws/lib/BufferUtil.js 35:21-42
# ./~/ws/lib/Receiver.js
# ./~/ws/index.js
# ./src/main.js
WARNING in ./~/ws/lib/Validation.js
Module not found: Error: Can't resolve 'utf-8-validate' in .../node_modules/ws/lib
# ./~/ws/lib/Validation.js 10:22-47
# ./~/ws/lib/Receiver.js
# ./~/ws/index.js
# ./src/main.js
WARNING in ./~/express/lib/view.js
80:29-41 Critical dependency: the request of a dependency is an expression
For the Critical dependency warning, I've found a good example explaining the problem and some documentation on how to use the ContextReplacementPlugin, although it's still unclear to me how to apply it to this situation. It looks like the warning is being caused by line 80 in node_modules/express/lib/view.js:
opts.engines[this.ext] = require(mod).__express
It is clear to me that the dependency cannot be resolved at build time, so how can I use the ContextReplacementPlugin to fix this dependency?
As for the Module not found warnings in the ws package, it's unclear to me what's going on. It looks like those dependencies exist in my global node_modules, and maybe they're not being pulled in by Webpack. I've tried adding them to my project's devDependencies, but then I just get Critical dependency warnings for them instead.
My application still runs after being built, so I suppose I could technically ignore the warnings, but I figure that these are widely used Node packages and Webpack is a popular build tool, so there must be a reasonable solution available.
Here are my dependencies in my package.json:
"devDependencies": {
"#types/cassandra-driver": "^0.8.10",
"#types/express": "^4.0.35",
"#types/uuid": "^2.0.29",
"#types/ws": "0.0.40",
"nodemon": "^1.11.0",
"typescript": "^2.3.1",
"webpack": "^2.5.1"
},
"dependencies": {
"cassandra-driver": "^3.2.1",
"express": "^4.15.2",
"uuid": "^3.0.1",
"ws": "^2.3.1"
}
And here's my webpack.config.js:
const path = require('path');
module.exports = {
entry: './src/main.js',
output: {
path: path.join(__dirname, 'dist'),
filename: 'main.js'
},
target: 'node',
node: {
__dirname: false,
__filename: false
}
};
I like keeping things minimal if possible. Thanks for reading.
The short answer
webpack can work with node, but it cannot extract follow require() statements. Modifications have to be made to ignore require() in order for it to work.
The long answer
It is actually possible to pull some files into a master file and run it in some instances.
One instance is if all the modules required are written in typescript and the modules are written in a away that the typescript plugin can parse the module in.
Another instance would be if you are using es6 babel plugins and using es6 style imports.
Even in the above scenarios the blunder may choose not to pull in certain files
The ultimate answer
It really should not matter too much about trying to perform the long answer because modules are stored in memory at boot and then referenced later from the cache. See the article below for more information.
http://fredkschott.com/post/2014/06/require-and-the-module-system/

Resources