I am creating a panel in Adobe Premiere Pro which used Google Cloud speech. I am accessing google-cloud/speech on the Javascript side, not JSX side via NodeJS. I am also accessing google-cloud/storage. No big deal, I installed NodeJS on a Mac and functions accessing google-cloud/storage were easy to code.
After following the instructions to npm --save #google-cloud/speech and npm --save #google-cloud/storage, it created the node_modules directory. I have moved them to a custom directory but they are duplicated in the standard location also.
In my code, I reference them as per the google-cloud examples:
// note cep.node is required in the Adobe CEP environment to access nodejs
const speech = cep_node.require(extention_path+'/lib/node_modules/#google-cloud/speech');
const project_id ='project_id_xxx1234';
const keyFilePath = extention_path +'/path/to/key.json';
const client = new speech.v1.SpeechClient({
projectId: project_id,
keyFilename: keyFilePath,
});
I've tried this w/o the ids and speech.SpeechClient() etc as per examples. The methodology is working fine with google-cloud/storage, so I know the similar downloaded node modules at the same location work fine for that.
However, it fails on trying to make a new speech.SpeechClient() with the browser debug error below.
Uncaught Error: Failed to load gRPC binary module because it was not installed for the current system
Expected directory: node-v51-darwin-x64-unknown
Found: [.DS_Store, node-v64-darwin-x64-unknown]
This problem can often be fixed by running "npm rebuild" on the current system
Original error: Cannot find module '/Library/Application Support/Adobe/CEP/extensions/com.iv.PProPanel/lib/node_modules/grpc/src/node/extension_binary/node-v51-darwin-x64-unknown/grpc_node.node'
at Object. (/Library/Application Support/Adobe/CEP/extensions/com.iv.PProPanel/lib/node_modules/grpc/src/grpc_extension.js:53:17)
at Module._compile (module.js:595:32)
at Object.Module._extensions..js (module.js:610:10)
at Module.load (module.js:512:32)
at tryModuleLoad (module.js:471:12)
at Function.Module._load (module.js:463:3)
at Module.require (module.js:522:17)
at require (internal/module.js:20:19)
at Object. (/Library/Application Support/Adobe/CEP/extensions/com.iv.PProPanel/lib/node_modules/grpc/src/client_interceptors.js:145:12)
at Module._compile (module.js:595:32)
My belief is that these series of node_modules that are accessed by #google-cloud/speech were compiled use NODE_MODULE_64 and need 51 (instead).
$ npm rebuild rebuilds (or checks current version of the modules) fine with the exception
protobufjs#6.8.8 postinstall /Library/Application Support/Adobe/CEP/extensions/com.iv.PProPanel/lib/node_modules/protobufjs
node scripts/postinstall
grpc#1.14.1 install /Library/Application Support/Adobe/CEP/extensions/com.iv.PProPanel/lib/node_modules/grpc
node-pre-gyp install --fallback-to-build --library=static_library
node-pre-gyp WARN Using request for node-pre-gyp https download
[grpc] Success: "/Library/Application Support/Adobe/CEP/extensions/com.iv.PProPanel/lib/node_modules/grpc/src/node/extension_binary/node-v64-darwin-x64-unknown/grpc_node.node" already installed
Pass --update-binary to reinstall or --build-from-source to recompile
So some module needs v51 instead of the build v64. The question is can the #google-cloud/speech modules be built using v51 and how? or do I wait for google-cloud to come up with a solution? BTW: I also renamed the node-v64 dir to node-51, but received another error referencing the MODULE 51. Any direction would be appreciated.
Some of the dependencies for #google-cloud/speech are native addons. Those being C/C++ code, they need to be compiled for the correct Node version. Looks like your Node version that you used for npm install doesn't match the one in Adobe CEP. Switch to Node 5.1 and run npm install or npm rebuild again.
I recommend using nvm to change Node versions, see Node Version Manager.
Related
My problem is that I want to import this library on a desktop app based on NW.js (the template is here).
import Cap from 'cap-rbfork' //set on a vue.js view
When I start the app, it doesn't load the page and I get this error on the window console:
VM245:11 Uncaught Error: The module '/home/user/app/node_modules/cap-rbfork/build/Release/cap.node'
was compiled against a different Node.js version using
NODE_MODULE_VERSION 83. This version of Node.js requires
NODE_MODULE_VERSION 72. Please try re-compiling or re-installing
the module (for instance, using `npm rebuild` or `npm install`). Please try re-compiling or re-installing
the module (for instance, using `npm rebuild` or `npm install`).
at Object.Module._extensions..node (:9080/internal/modules/cjs/loader.js:955)
at Module.load (:9080/internal/modules/cjs/loader.js:756)
at Function.Module._load (:9080/internal/modules/cjs/loader.js:669)
at Module.require (:9080/internal/modules/cjs/loader.js:796)
at require (:9080/internal/modules/cjs/helpers.js:68)
at Object.<anonymous> (:9080/home/user/app/node_modules/cap-rbfork/lib/Cap.js:3)
at Module._compile (:9080/internal/modules/cjs/loader.js:893)
at Object.Module._extensions..js (:9080/internal/modules/cjs/loader.js:910)
at Module.load (:9080/internal/modules/cjs/loader.js:756)
at Function.Module._load (:9080/internal/modules/cjs/loader.js:669)
#Jaredcheeda
I followed your instructions, and I created a new NWjs app with the template you suggested.
mounted(){
var Cap = this.nw.require('cap-rbfork')
console.log(Cap) //it lists properties
console.log(Cap.Cap.deviceList()) //or Cap.deviceList(), but the app crashes anyway, without reporting the reason, except SIGSEGV
}
If I visit the page from the browser, I get this error:
vue.runtime.esm.js?2b0e:1897 Error: Module parse failed: Unexpected character '' (1:0)
You may need an appropriate loader to handle this file type, currently no loaders are configured to process this file. See https://webpack.js.org/concepts#loaders
(Source code omitted for this binary file)
at eval (cap.node:1)
at Object../node_modules/cap-rbfork/build/Release/cap.node (chunk-vendors.js:22)
at __webpack_require__ (app.js:849)
at fn (app.js:151)
at eval (Cap.js?c745:3)
at Object../node_modules/cap-rbfork/lib/Cap.js (chunk-vendors.js:33)
at __webpack_require__ (app.js:849)
at fn (app.js:151)
at VueComponent.mounted (App.vue?234e:37)
at invokeWithErrorHandling (vue.runtime.esm.js?2b0e:1863)
I don't know this means that NW needs to be downgraded, so it can match the correct node-gyp version. I created an Electron project, and following this answer to a similar problem, it worked. Is there a NW equivalent to electron-rebuild?
Completely uninstall your globally installed version of Node
Install a Node Version Manager:
Linux/OSX - https://github.com/nvm-sh/nvm
Windows 8+ - https://github.com/coreybutler/nvm-windows
Windows 7 - https://github.com/nullivex/nodist
Check the version of Node that is built in to NW.js
https://nwjs.io/versions.json
or console.log(process.versions); in NW.js
Use your nvm tool of choice to install and switch to the matching Node version
Delete the package-lock.json and node_modules folder
Do npm install this will download/build files specific to your global Node versions, which should match the version built in to NW.js
With all that said, Vue-CLI's Webpack/Babel set up is designed to import/bundle/tree-shake BROWSER code, not NODE code. So doing import x from 'y' won't work if it involves native code, node-bindings, executables, or Node specific code.
NW.js uses require instead of import to handle importing Node modules.
See: NW-Vue-CLI-Example
You may also need to change your NW.js version if you are having issues with Node-GYP/NW-GYP:
See: https://dev.to/thejaredwilcurt/guide-to-nw-js-versions-5d38#0392-20190627
React Native new init app not able to run via xcode or via npm run ios.
System - Mac
Npm - 6.14.12
node - v14.16.1
react-native - 2.0.1
>>>>> Generating schema from flow types
/Users/admin/Documents/ios/MyProject/node_modules/react-native-codegen/lib/parsers/flow/index.js:220
const regex = new RegExp(TURBO_MODULE_REGISTRY_REQUIRE_REGEX_STRING, 'g');
^
SyntaxError: Invalid regular expression: /TurboModuleRegistry\s*\.\s*get(Enforcing)?\s*<\s*Spec\s*>\s*\(\s*['"](?<nativeModuleName>[A-Za-z$_0-9]+)['"]\s*,?\s*\)/: Invalid group
at new RegExp (<anonymous>)
at buildSchema (/Users/admin/Documents/ios/MyProject/node_modules/react-native-codegen/lib/parsers/flow/index.js:220:19)
at Object.parseFile (/Users/admin/Documents/ios/MyProject/node_modules/react-native-codegen/lib/parsers/flow/index.js:276:10)
at files.reduce (/Users/admin/Documents/ios/MyProject/node_modules/react-native-codegen/lib/cli/combine/combine-js-to-schema.js:75:35)
at Array.reduce (<anonymous>)
at combineSchemas (/Users/admin/Documents/ios/MyProject/node_modules/react-native-codegen/lib/cli/combine/combine-js-to-schema.js:66:16)
at Object.<anonymous> (/Users/admin/Documents/ios/MyProject/node_modules/react-native-codegen/lib/cli/combine/combine-js-to-schema-cli.js:90:40)
at Module._compile (internal/modules/cjs/loader.js:654:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:665:10)
at Module.load (internal/modules/cjs/loader.js:566:32)
Command PhaseScriptExecution failed with a nonzero exit code
This was an issue where the react-native-codegen reference in react-native was set to v0.0.6. In the newer 0.0.7 version a lot changed in the parser. It looks like back in February of 2021 the reference was updated to 0.0.7 which is also a part of react-native#0.65.0.
If you check out the package.json file in the react-native package I am guessing it is referencing the 0.0.6 version of the codegen package. You could update react-native (I see you referenced it as 2.0.1 in your post, but check the package.json file in the react-native folder to see what you have). You can also add the new version of codegen like this:
npm install --save-dev react-native-codegen#0.0.7
I recommend updating react-native if you can, but the codegen package update just in the root package.json also works for now.
I'm trying to develop an electron app, and I would like to use an npm package that gives vibrancy to a window. This is the package I'm trying to use: https://github.com/sebascontre/windows10-fluently-vibrancy
It uses a visual c++ code to call native windows methods to achieve this vibrancy effect.
I've cloned and I've run the npm install and build as described in the readme and ran the following:
npm install
npm run conf
npm run rebuild
All built successfully and I also see the build\debug artifacts of the c++ build.
When I try to run it (as described in readme):
cd spec\app
electron .
I'm getting the following error message:
Uncaught Exception:
Error: The specified module could not be found.
\\?\F:\Development\windows10-fluently-vibrancy\build\Debug\Vibrancy.node
at process.func [as dlopen] (electron/js2c/asar.js:155:31)
at Object.Module._extensions..node (internal/modules/cjs/loader.js:857:18)
at Object.func [as .node] (electron/js2c/asar.js:155:31)
at Module.load (internal/modules/cjs/loader.js:677:32)
at tryModuleLoad (internal/modules/cjs/loader.js:609:12)
at Function.Module._load (internal/modules/cjs/loader.js:601:3)
at Module.require (internal/modules/cjs/loader.js:715:19)
at require (internal/modules/cjs/helpers.js:14:16)
at bindings (F:\Development\windows10-fluently-vibrancy\node_modules\bindings\bindings.js:112:48)
at Object.<anonymous> (F:\Development\windows10-fluently-vibrancy\index.js:1:35)
According to the message it cannot find the Vibrancy.node file - But I've verified that it exists in the specified location.
Any ideas how to make it run? I have cloned the package to test it since when trying to use the npm itself in my project it gave the same error so I figured I would try the source.
Today I had the exact same issue you're describing here.
I got it to work using electron-rebuild.
From the root of your project run the command: electron-rebuild
Hope this helps you, if not, maybe someone else.
This is similar to this Electron Uncaught Error: A dynamic link library (DLL) initialization routine failed
ELECTRON_ASAR.js:173
return old.apply(this, arguments)
^
Error: A dynamic link library (DLL) initialization routine failed.
\\?\C:\workspace\client\client\desktop\node_modules\sqlite3\lib\binding\node-v57
-win32-x64\node_sqlite3.node
at process.module.(anonymous function) [as dlopen] (ELECTRON_ASAR.js:173:20)
at Object.Module._extensions..node (module.js:671:18)
at Object.module.(anonymous function) [as .node] (ELECTRON_ASAR.js:173:20)
at Module.load (module.js:561:32)
at tryModuleLoad (module.js:504:12)
at Function.Module._load (module.js:496:3)
at Module.require (module.js:586:17)
at require (internal/module.js:11:18)
at Object.<anonymous> (C:\workspace\client\client\desktop\node_modules\sqlit
e3\lib\sqlite3.js:4:15)
at Object.<anonymous> (C:\workspace\client\client\desktop\node_modules\sqlit
e3\lib\sqlite3.js:190:3)
I've tried everything suggested in this post and anything else I can find
I've installed electron-rebuild and added "rebuild": "electron-rebuild -f -w sqlite3 -V 1.7"
This is running without errors.
I tried "postinstall": "install-app-deps",
This isn't helping..
Anything else to try?
The files are in there..
The
This ended up being a mashup of a bunch of different issues on my end. I'll start with the simplest and go from there.
Platform
Your error there indicates that it wants node-v57-win32-x64, but if you are running from Electron it should be electron-v2.0-win32-x64 (or electron-v1.7-win32-x64 if you are using an older version). I ran into this as well because I am running sqlite3 in a child process. Child processes in Electron are in a full node context and not an Electron (browser or node+browser) context. I fixed this by passing the Electron version from the main browser process (process.versions.electron) to the child process via an environment variable and setting it on process.versions.electron in the child process.
WARNING: that is a HACK and works because I'm not using anything that expects a full Electron environment in that process. It is literally only to make it find the correct native bindings. A more correct fix would be to look into making electron-builder build node-v57-win32-x64 instead.
Speaking of which, let's create those next.
postinstall
"scripts": {
...
"postinstall": "electron-builder install-app-deps"
}
This should attempt to rebuild your native dependencies when running npm install or yarn install. If you have a project/app directory, they will be placed in project/app/node_modules/. Otherwise they'll go in project/node_modules.
Transitive Dependency
In my case, sqlite3 is actually a transitive dependency of another package in my dependency set. While electron-builder on Linux/OS X picked these up correctly and showed this during installer creation:
• rebuilding native production dependencies platform=linux arch=x64
• rebuilding native dependency name=sqlite3
the Windows build showed:
• no native production dependencies
This was fixed by adding the transitive dependency as a direct dependency. After I did this, the package started to be picked up by electron-builder for compilation and was spitting out errors.
Windows Build
To fix those errors:
Install python (I used the latest 2.7)
Install Microsoft Build Tools 2013 and restart
run your postinstall script again
This is the point where I said it was "half-solved" on my end. This should be the full solution for basic electron project setups.
yarn workspaces
I use the yarn workspaces feature and my project setup is something like this:
yarn-workspace-project/
workspace/
project/
web-app/
project-electron/
app/
For this kind of setup, yarn install is generally run in the yarn-workspace-project or yarn-workspace-project/workspace directory, rather than in each project. This produces a hoisted node_modules/ directory at yarn-workspace-project/node_modules. When creating the packaged version, electron-builder grabs the dependencies from that hoisted location and everything runs.
When running my start script in project-electron, however, electron . had some issues finding the native binding. The package using sqlite3 was installed under yarn-workspace-project/node_modules, and was therefore resolving sqlite3 to yarn-workspace-project/node_modules/sqlite3. This definitely exists per the yarn install, but the electron bindings got put in yarn-workspace-project/workspace/project-electron/app/node_modules/sqlite3.
There are multiple obvious solutions to that, so I'll leave that as an exercise to the reader. The key problem here is that the default bindings that get downloaded (I think? I don't recall them being built) for node-v57-win32-x64 do not work out of the box for Windows 10 like they do for Linux / OS X, even though the error indicates that they don't exist (which they do).
Has anyone been able to successfully install node-sass on IBM i?
I'm currently running Node 6.9.1, and am able to install many npm packages. However, the #angular/cli has a dependency on node-sass, and apparently, node-sass has a compiled component that is giving me grief to install.
My first issue had to do with being able to download the binary itself - because of our network setup, the IBM i was unable to download the binary from:
https://github.com/sass/node-sass/releases/download/v4.5.2/aix-ppc-48_binding.node
I was getting a timeout error. I was able to resolve that by changing the SASS_BINARY_SITE to the non-https version:
export SASS_BINARY_SITE='http://github.com/sass/node-sass/releases/download'
However, now, even though the binary downloads successfully, i get the following error when npm tries to test the binary:
Testing binary Binary has a problem: Error: Could not load module
/QOpenSys/QIBM/ProdData/OPS/Node6/lib/node_modules/node-sass/vendor/aix-ppc-48/binding.node.
The module has an invalid magic number.
at Error (native)
at Object.Module._extensions..node (module.js:597:18)
at Module.load (module.js:487:32)
at tryModuleLoad (module.js:446:12)
at Function.Module._load (module.js:438:3)
at Module.require (module.js:497:17)
at require (internal/module.js:20:19)
at module.exports (/QOpenSys/QIBM/ProdData/OPS/Node6/lib/node_modules/node-sass/lib/binding.js:19:10)
at Object.<anonymous> (/QOpenSys/QIBM/ProdData/OPS/Node6/lib/node_modules/node-sass/lib/index.js:14:35)
And then npm tries to build the binary locally, but fails because Python2 isn't available on this machine. I can request the installation of Python2, which is a long process in our environment, but before i continue down that rabbit hole, I'd like to know if it's actually possible to have node-sass working, and if so, is there another binary that i can point the npm install at to use instead.
Or, is there an alternative means of get node-sass working?
As of 2017 this will likely not be possible. In addition to Python you will need the entire cpp toolchain to build node and node addons. Since this is already a very hard requirement for desktop PCs, systems like that will have a even harder time. Judging from their binding.gyp, there is just support for OS X, Windows and Linux.
node-sass is known to be hard to build also across the node use base.
Very likely you rather want to have a build / CI step on Linux that compiles your SASS files and builds your artefact.