I want to mock a http request in Vue.js using Vitest. How can I perform testing for http requests
I use unplugin-vue-define-options LTS in my Vue.js 3 + Vite 3. After running my app, the following error is appeared.
[vite] Internal server error: unplugin-vue-define-options TypeError: Cannot read properties of undefined (reading 'scriptSetupAst')
I also reinstall the package, but there is still the above error.
I was having the same problem. But today I updated to the latest version released (1.1.3) and apparently this bug has been fixed.
I'm trying to develop and deploy some firebase cloud functions using the firebase cli on Windows 7. I'm trying to set up my development environment from my office where the network is behind a corporate proxy.
In the past I have configured node.js and npm to work behind the proxy and I do not have any problems downloading dependencies.
Now when I started a firebase project I did not have any problem logging into my Firebase account. However when I tried to:
firebase use --add
in my project folder I get the following error message:
Error: Server Error. unable to get local issuer certificate
From the firebase-debug.log I get more info:
[debug] [2017-10-16T14:43:42.993Z] >>> HTTP REQUEST GET https://admin.firebase.com/v1/projects Mon Oct 16 2017 16:43:42 GMT+0200 (ora legale Europa occidentale)
[debug] [2017-10-16T14:43:43.587Z] Error: unable to get local issuer certificate at Error (native) at TLSSocket.<anonymous>(_tls_wrap.js:1092:38) at emitNone (events.js:86:13) at TLSSocket.emit (events.js:185:7) at TLSSocket._finishInit (_tls_wrap.js:610:8) at TLSWrap.ssl.onhandshakedone (_tls_wrap.js:440:38)
[error]
[error] Error: Server Error. unable to get local issuer certificate
I tried to use
npm config set cafile "<path-to-a-cert-extracted-from-cacert.pem>"
with no luck.
I really can't figure out what's going on and I couldn't find any solution on the web.
On StackOverflow there's a similar question but the answers seem to point to a different problem.
I would be glad to hear if someone has found a solution to this problem. Thanks.
Ok so basically after 2 days of research I finally came up with a (hack)solution by looking at Node.js documentation on TLS.
Setting the following environment variable does the trick:
set NODE_TLS_REJECT_UNAUTHORIZED=0
I personally don't like this solution but at least it makes me work.
Is this something that has to be fixed?
Or am I missing something on the configuration of npm behind a proxy?
Thanks.
I'm trying to upgrade my Grafana setup from version v4.0.2 (commit: v4.0.2) to version v4.4.3 (commit: 54c79c5) on CentOS 7. Both old and new versions of Grafana are installed from official RPM packages.
When I'm trying to open any dashboard that I have I'm getting a following error message:
Templating init failed
Maximum call stack size exceeded
Also in the browser console log I see the following messages:
RangeError: Maximum call stack size exceeded
at RegExp.exec (<anonymous>)
at RegExp.[Symbol.replace] (<anonymous>)
at String.replace (<anonymous>)
at Object.replace (http://<my_grafana_host>/public/app/boot.07485e0c.js:10:23129)
at Object.get (http://<my_grafana_host>/public/app/boot.07485e0c.js:45:5205)
at Object.get (http://<my_grafana_host>/public/app/boot.07485e0c.js:45:5235)
at Object.get (http://<my_grafana_host>/public/app/boot.07485e0c.js:45:5235)
at Object.get (http://<my_grafana_host>/public/app/boot.07485e0c.js:45:5235)
at Object.get (http://<my_grafana_host>/public/app/boot.07485e0c.js:45:5235)
at Object.get (http://<my_grafana_host>/public/app/boot.07485e0c.js:45:5235) <plugin-component type="query-ctrl">
I'm getting the same error in browser console when I'm trying to Save & Test settings in Graphite datasource. In this case I'm seeing a progress bar that says Testing... but never completes.
I've checked behaviour in Chrome and Firefox and it breaks in the same way in both browsers.
I've double-checked and graphite is up and running and is listening on the selected URL. Also when I'm trying to revert the change and run Grafana 4.0.2 it does work with the same settings.
I've also tried to run new Grafana with default configuration coming from RPM with no luck.
I know that's not much information and I would be glad to provide any additional info that might help resolving this issue.
I'm trying to start a new mean stack application. However i only get this error when I'm running grunt to start the server:
[nodemon] v1.2.1
Running "watch" task
[nodemon] to restart at any time, enter `rs`
[nodemon] watching: *.*
[nodemon] starting `node --debug server.js`
Waiting...
Debugger listening on port 5858
Mean app started on port 3000 (development) cluster.worker.id: 0
/Users/olehenrik/Sites/learn/mean_test2/node_modules/mongoose/node_modules/mongodb/lib/mongodb/connection/base.js:246
throw message;
^
TypeError: Cannot read property 'length' of undefined
at processResults (/Users/olehenrik/Sites/learn/mean_test2/node_modules/mongoose/node_modules/mongodb/lib/mongodb/db.js:1581:31)
at /Users/olehenrik/Sites/learn/mean_test2/node_modules/mongoose/node_modules/mongodb/lib/mongodb/db.js:1619:20
at /Users/olehenrik/Sites/learn/mean_test2/node_modules/mongoose/node_modules/mongodb/lib/mongodb/db.js:1157:7
at /Users/olehenrik/Sites/learn/mean_test2/node_modules/mongoose/node_modules/mongodb/lib/mongodb/db.js:1890:9
at Server.Base._callHandler (/Users/olehenrik/Sites/learn/mean_test2/node_modules/mongoose/node_modules/mongodb/lib/mongodb/connection/base.js:448:41)
at /Users/olehenrik/Sites/learn/mean_test2/node_modules/mongoose/node_modules/mongodb/lib/mongodb/connection/server.js:481:18
at MongoReply.parseBody (/Users/olehenrik/Sites/learn/mean_test2/node_modules/mongoose/node_modules/mongodb/lib/mongodb/responses/mongo_reply.js:68:5)
at null.<anonymous> (/Users/olehenrik/Sites/learn/mean_test2/node_modules/mongoose/node_modules/mongodb/lib/mongodb/connection/server.js:439:20)
at emit (events.js:107:17)
at null.<anonymous> (/Users/olehenrik/Sites/learn/mean_test2/node_modules/mongoose/node_modules/mongodb/lib/mongodb/connection/connection_pool.js:201:13)
[nodemon] app crashed - waiting for file changes before starting...
Have any one encountered this before? Can't find too many other people who have encountered this before.
I was also facing the same error and this info solves it.
"Upgrade to 3.8.23. 3.8.22 introduced better compatibility with mongodb server 3.0 by upgrading to latest version of the driver." credit to vkarpov15 from mongoose Github thread.
What I did was I edit my package.json to upgrade mongoose to "3.8.23". After I edited the package.json I ran npm install and bower install(just to make sure) again and that solved the problem.
When trying to run meteor in cloud9 I encounter one of the following errors:
Running the older modified version from cloud9 I get the error:
No dependency info in bundle. Filesystem monitoring disabled.
=> Errors prevented startup:
Exception while bundling application:
Error: Package not found: standard-app-packages
at self.api.use (/var/lib/stickshift/532a1c97500446885f0002a8/app-root/data/meteor/tools/bundler.js:113:17)
at Array.forEach (native)
at Function._.each._.forEach (/var/lib/stickshift/532a1c97500446885f0002a8/app-root/data/meteor/dev_bundle/lib/node_modules/underscore/underscore.js:79:11)
at Object.self.api.use (/var/lib/stickshift/532a1c97500446885f0002a8/app-root/data/meteor/tools/bundler.js:110:9)
When I try running the lastest version, I get an error from cloud9:
Cloud9 Error: you may be using the wrong PORT & HOST for your server app
Node: use 'process.env.PORT' as the port and 'process.env.IP' as the host in your scripts. See also https://c9.io/site/blog/2013/05/can-i-use-cloud9-to-do-x/
In both cases, I clone the corresponding GitHub repository and run export BIND_IP=$IP as well as export PORT=20000 (as it is described in on several posts). I also gave up the hope using the default MongoDB server and am instead exporting MONGO_URL to a free database hosted on https://www.mongohq.com/.
I've also tried to merge the pull request from cloud9's meteor version to the master, but those files don't even exist anymore. Everything else I could find was about Meteor version 0.6.5 and 0.5
Trying to modify the latest Meteor-version I looked for the httpServer.listen call, but I found only one in meteor/packages/webapp/webapp_server.js, and it seems that the cloud9 error is thrown before that part of code is reached (if it is ever reached). So that there must be a another piece of code which is bound to the wrong address or port.
The plugins I use are:
standard-app-packages
insecure
preserve-inputs
underscore
backbone
jquery
accounts-ui
accounts-base
accounts-password
accounts-facebook
accounts-google
coffeescript
Update:
After some more hours looking for a solution, I got much further. The problem was in meteor/tools/run-proxy.js:
In line 94 you can see: self.server.listen(self.listenPort, function () { here is the corresponding IP-address missing to which the server should bind itself. Now meteor used to use an environmental variable BIND_IP which we could introduce here again, but this would have unnecessary additional changes on cloud9, since they export the current IP address to which a service should bind itself in the IP variable. So I changed the line in question to: self.server.listen(self.listenPort, process.env.IP, function () {
I've also additionally modified meteor/tools/run-all.js, since I wasn't sure if the correct port parameter is used. On line 24 I exchanged var listenPort = options.port; with var listenPort = process.env.PORT;
While I can now finally start the application, it is still not running and I'm getting the following output:
=> Running Meteor from a checkout -- overrides project version (0.7.2)
[[[[[ ~/<PROJECT_ID>/<PROJECT_NAME> ]]]]]
=> Started proxy.
W20140321-22:31:42.591(-4)? (STDERR)
W20140321-22:31:43.036(-4)? (STDERR) events.js:72
W20140321-22:31:43.037(-4)? (STDERR) throw er; // Unhandled 'error' event
W20140321-22:31:43.037(-4)? (STDERR) ^
Cloud9 Error: you may be using the wrong PORT & HOST for your server app
Node: use 'process.env.PORT' as the port and 'process.env.IP' as the host in your scripts. See also https://c9.io/site/blog/2013/05/can-i-use-cloud9-to-do-x/
W20140321-22:31:43.108(-4)? (STDERR) Error: listen EACCES
W20140321-22:31:43.109(-4)? (STDERR) at errnoException (net.js:901:11)
W20140321-22:31:43.109(-4)? (STDERR) at Server._listen2 (net.js:1020:19)
W20140321-22:31:43.111(-4)? (STDERR) at listen (net.js:1061:10)
W20140321-22:31:43.111(-4)? (STDERR) at net.js:1143:9
W20140321-22:31:43.112(-4)? (STDERR) at dns.js:72:18
W20140321-22:31:43.112(-4)? (STDERR) at process._tickCallback (node.js:415:13)
=> Exited with code: 8
However meteor doesn't crash and the exceptions keep coming in one after another. That's why I first thought, the exception is due to an authentication error on MongoDB, since also Error-Code 8 for MongoDB is authentication error, but this is what I get when I use an invalid username + password on my MongoHQ-hosted database:
[...]
=> Started proxy.
W20140321-22:54:17.282(-4)? (STDERR)
W20140321-22:54:18.700(-4)? (STDERR) /var/lib/stickshift/532a1c97500446885f0002a8/app-root/data/meteor/packages/mongo-livedata/.build/npm/node_modules/mongodb/lib/mongodb/mongo_client.js:400
W20140321-22:54:18.777(-4)? (STDERR) throw err
W20140321-22:54:18.778(-4)? (STDERR) ^
W20140321-22:54:18.778(-4)? (STDERR) MongoError: auth fails
W20140321-22:54:18.778(-4)? (STDERR) at Object.toError (/var/lib/stickshift/532a1c97500446885f0002a8/app-root/data/meteor/packages/mongo-livedata/.build/npm/node_modules/mongodb/lib/mongodb/utils.js:110:11)
W20140321-22:54:18.779(-4)? (STDERR) at /var/lib/stickshift/532a1c97500446885f0002a8/app-root/data/meteor/packages/mongo-livedata/.build/npm/node_modules/mongodb/lib/mongodb/auth/mongodb_cr.js:34:33
W20140321-22:54:18.779(-4)? (STDERR) at /var/lib/stickshift/532a1c97500446885f0002a8/app-root/data/meteor/packages/mongo-livedata/.build/npm/node_modules/mongodb/lib/mongodb/db.js:1670:9
W20140321-22:54:18.779(-4)? (STDERR) at Server.Base._callHandler (/var/lib/stickshift/532a1c97500446885f0002a8/app-root/data/meteor/packages/mongo-livedata/.build/npm/node_modules/mongodb/lib/mongodb/connection/base.js:382:41)
W20140321-22:54:18.780(-4)? (STDERR) at /var/lib/stickshift/532a1c97500446885f0002a8/app-root/data/meteor/packages/mongo-livedata/.build/npm/node_modules/mongodb/lib/mongodb/connection/server.js:472:18
W20140321-22:54:18.780(-4)? (STDERR) at MongoReply.parseBody (/var/lib/stickshift/532a1c97500446885f0002a8/app-root/data/meteor/packages/mongo-livedata/.build/npm/node_modules/mongodb/lib/mongodb/responses/mongo_reply.js:68:5)
W20140321-22:54:18.780(-4)? (STDERR) at null.<anonymous> (/var/lib/stickshift/532a1c97500446885f0002a8/app-root/data/meteor/packages/mongo-livedata/.build/npm/node_modules/mongodb/lib/mongodb/connection/server.js:430:20)
W20140321-22:54:18.781(-4)? (STDERR) at EventEmitter.emit (events.js:95:17)
W20140321-22:54:18.781(-4)? (STDERR) at null.<anonymous> (/var/lib/stickshift/532a1c97500446885f0002a8/app-root/data/meteor/packages/mongo-livedata/.build/npm/node_modules/mongodb/lib/mongodb/connection/connection_pool.js:191:13)
W20140321-22:54:18.782(-4)? (STDERR) at EventEmitter.emit (events.js:98:17)
=> Exited with code: 8
This error is thrown in meteor/packages/mongo-livedata/mongo_driver.js at line 149:
147: MongoDB.connect(url, mongoOptions, function(err, db) {
148: if (err)
149: throw err;
150: self.db = db;
This is also OK, however I couldn't find where the other error comes from, which occurs, when my credentials are correct.
I just ran into similar issues initially, but the latest version of Meteor (0.9.0) makes this easy at least.
meteor run --port=$IP:$PORT
Seems to do the trick (at least so far)
This is doc'd in
meteor help run
hth
Andy
Ok, so actually the first part of the question is the correct answer, if I hadn't done it the other way around:
BIND_IP is used within meteor/packages/webapp/webapp_server.js, but not in meteor/tools/run-proxy.js. However both need to bind to cloud9's 'IP'-variable.
So to solve this issue, simply update the proxy, similar as I did it, to use the correct IP-address: self.server.listen(self.listenPort, process.env.IP, function () {
and just write in your .bashrc export BIND_IP=$IP
now everything works smoothly (provided, that you use a mongodb outside of cloud9)
I've summarised the necessary steps in my blog: http://peter.grman.at/how-to-run-meteor-in-cloud9/
meteor works very nice in c9.io, i am working in c9.io with metor. just following the steps.
select workshop as nodejs.
in terminal write the command "curl https://install.meteor.com/ | sh"
in terminal write $ meteor create newapp(your main application folder name)
in terminal write cd newapp
in terminal write $ meteor -p 8080 (note -p or --port, if you using port as 300 that not working properly in c9.io . so you should using port as 8080 or 8081 or 8082)
after few seconds you get a link app running at: localhost:8080
click the link and open it.
Meteor 1.4:
At first, I tried a lot of different variations, with and without the --port flag mentioned in Andrew's answer.
If I only ran the meteor command without any flag, the app would successfully start on port 3000, but apparently that port can't be used in Cloud9 (https://docs.c9.io/docs/multiple-ports)
If I used the --port flag, meteor would just hang on "Starting your app"
Most likely something got stuck along the way (with all the retries), because what probably finally fixed it was to run a meteor reset before starting the app (Meteor application - Stuck at "Starting your app" when trying to run):
...$ sudo meteor reset
...$ sudo meteor --port=$IP:$PORT
If that doesn't help, I had also added some detailed logging on the attempt that finally worked (see this meteor forum post: Meteor stuck at starting your app). Try this if you're still stuck:
...$ sudo meteor reset
...$ METEOR_PROFILE=1
...$ METEOR_LOG=debug
...$ sudo meteor --port=$IP:$PORT --verbose
After it worked the first time, I can now start the app with only one command:
...$ sudo meteor --port=$IP:$PORT