I have ran into trouble with ipfs-http-client in my React app.
I'm using node 16.14.0
The error message is:
When I Ctrl + Click on 'ipfs-http-client', it still drive me to the modules file.
Solutions that I've tried, but not work:
Restart app
Reinstall module
I've tried use 33.x version, it works fine but I want to use the latest version of ipfs-http-client (57.0.3)
Please help me. Thanks a lot!
The simple Solution
When you use ipfs-http-client in the frontend you will soon also have problems using jest. The easiest way is to simply not use ipfs-http-client at all and instead use a gateway like infura and fetch() the data directly. You can use my code for that:
https://gist.github.com/aignermax/c495c98003da974d17b9c4c481ac23be
The more tricky one
The problem seems to be related to webpack 5 that does not support any Node.js functions "polyfills" anymore. The idea is to keep the frontend separate from the backend and all ipfs-http-client functions are meant to be used in backend only.
You can however still add the polyfills manually following this tutorial: Remember that "Jest" will still not work after that, so if you do unit testing you should consider using ipfs on your server instead or use "The simple Solution" above.
https://github.com/facebook/create-react-app/issues/11756#issuecomment-1001162736
I then got some webpack PolyErrors which I solved using this NPM Package:
https://www.npmjs.com/package/node-polyfill-webpack-plugin
I also Got Errors about failed to load Source-Map from source-map-loader, which will occur using WebPack5 which is included in the new React-Scripts. You fix that by using this:
Failed to parse source map
and NOW IT WORKS.
Related
I am new to development on Jira Cloud and am currently exploring creating apps using the Atlassian Forge. I was trying to use Express JS in the code as a middleware. Turns out that during deployment, it keeps giving this error "process.cwd is not a function."
The error received while deploying the app.
I tried installing process module (via npm i process; which was successfully done) and updating the webpack version but none of it worked.
Can someone please tell what could be causing this error?
If possible please suggest the alternative for using Express JS in Altassian Forge?
Thanks in advance.
Apoorva
From the documentation:
When a Forge app is invoked, the JavaScript code is executed within the app sandbox. This environment differs from a traditional Node.js environment you might already be familiar with.
You'll need to write your functions in a subset of Node.js. Some globals are not exposed, for example:
process (except for process.env)
queueMicrotask
which means that some NPM packages that depend on these may not function correctly.
If Express JS depends on process.cwd(), that would explain the error. You may be able to work around this if it depends on it in theory but not in practice:
If process.cwd() is only used in test cases or example code, you can delete it or make sure it's not bundled.
If it is used, but using a dummy string like "/" would work, you could stub out the call using DefinePlugin or similar.
I previously tested and used worker_threads in my project.
Now when attempting to npm run serve or npm run build I'm getting the following error:
This dependency was not found:
worker_threads
I am running node --version v14.17.2 so I know that worker_threads are supported.
I have even created a clean project with Vue CLI and when adding the following code, I still see the same error.
const {
Worker, isMainThread, parentPort, workerData
} = require('worker_threads');
I've searched extensively, but all of the problems and solutions relate to earlier versions of the node that did not support it.
I'm at a loss as to how to solve this. Suggestions are greatly appreciated.
Edit: I've updated all possible modules in the project in case there might be some sort of conflict, but the problem still persists.
My mistake.
The code I wrote to use worker_threads was originally tested in a pure node.js (sever side) environment. The code ended up being required in a Vue component, which of course is browser based, so of course, worker_threads are not available as they are server side.
A solution would be to make a server API call to the code, or to use something such as threads.js which provides a unified API for worker_threads (sever side) and web workers which are browser based (client side).
I initialized a brand new Next.js project and installed the official openlayers module (https://github.com/openlayers/openlayers) with npm in it.
But as soon as I import it in one of the src js files, I get some error like this: Unexpected token 'export'
The only way I got it working is by telling Next.js to not use that src file on the server side.
I understand that it only wants to work with client side rendering.
Can anyone explain to me, why is it only working like that?
What is different in this module that prevents it from using it with the default ssr settings?
OpenLayers got full node.js support since I posted my question, so with that it become obsolete.
Find more about it on their GitHub repo.
I'm trying to use the serialization API from the node.js v8 module in my react app (created with create-react-app) but it doesn't seem to work.
According to the documentation it should just be a case of importing/requiring the module. When I try this, it all appears to be working as expected - no errors. I can even access methods like .serialize() and .deserialize() on the v8 object too - great. But when I try to actually run my project (using react-scripts start) I get a compilation error:
Module not found: Can't resolve 'v8' in '...'
Is it looking for a file called "v8.js" to import rather than using the node module for some reason? How do I get around this?
node_modules is only a concept when working within the node ecosystem. So it is only possible to import "v8" when within a node process.
Since you ask about a "react app" that seems to imply that you are writing something for the browser. Which now has modules which use import/export (similar to require/module.exports from node), however, that still doesn't mean that the "v8" package will be present.
Many of node's packages are C++ backed (or to use the technical term, they are "native packages") instead of being purely written in JS. Also, it should be noted that unlike dependencies listed in your "package.json" file, none of the node packages are actually downloaded when you run npm install since they are all bundled with your installation of node.
To make a long story short, I'd like to run my jest tests (using CLI) with electron instead of node.
It's relevant when using native module, because you need to build them using electron header while jest run them using plain node.
So I must either build my native modules for my app (at least in dev mode) or my tests, I can't have both to work.
In this thread they propose to use mocha, but I want to use jest, which is far more advanced and interact well with React.
Note that I don't want to mock the native module, since I write integration tests.
I opened an issue about the zmq github repo. One proposed solution is "to target your tests using ELECTRON_RUN_AS_NODE=true electron as your node runtime".
This is a very good solution, since using electron will both make the test environment closer to the execution environment and solve my specific issue with native modules.
I'd like to apply that, but I do no seem to be able to setup the jest CLI to use electron instead of node, and I have no idea where to start. Maybe I should run jest programmatically without the CLI ? But I might lose the nice test filtering features of the CLI.
Has anyone solved this already?
"ELECTRON_RUN_AS_NODE=true ./node_modules/.bin/electron ./node_modules/.bin/jest works fine
If you're on Windows, then Eric Burel's excellent discovery might need a bit of a tweak to use the environment variable, and call the right version of Jest:
cross-env ELECTRON_RUN_AS_NODE=true ./node_modules/.bin/electron ./node_modules/jest-cli/bin/jest.js
Sadly, the colouring of the text in the results is lost.