Normally, in order to know that it's started, there's a message in Node that says "info - socket.io started". However, for some reason, I'm not getting it. Could be a version thing.
So is there another way to know if my socket is up and listening?
Have you recently updated Socket.io from version 0.9 to 1.x? The default values for log reporting changed with version 1.0, and it's less verbose by default.
See the upgrade documentation.
PS: If you upgraded Socket.io and you didn't even realize it, then it's because your "package.json" file does not lock versions. I'd strongly advise AGAINST using * as version: always be more specific, locking the versions at least to the minor version (as per semver). For example:
// In package.json, under "dependencies":
// NOT SAFE: this always gets the last version, which may have some breaking change (as per semver, with version X.Y.Z, changes in X allow breaking changes in APIs)
"socket.io": "*"
// POSSIBLY SAFE: this does not update to the new major version, so API compatibility *should* be always maintained (however, it's not 100% safe too, to be used carefully)
"socket.io": "1.x"
// SAFE: this allows updates that contain bug fixes and minor additions; API-compatibility should always be guaranteed
"socket.io": "1.0.x"
"socket.io": "1.0.*" // equivalent
"socket.io": "~1.0.4" // equivalent
Related
I'm using these versions: "mongodb": "^3.6.3", "mongoose": "^5.10.18" and I'm having an issue where sometimes when I do a mongo SomeModel.create() in a cron job, it fails because of this error:
TypeError: Right-hand side of 'instanceof' is not an object and it fails on the node_modules/mongoose line in the screenshot below. This used to work completely fine and one day it just started happening without me changing the package versions or any other related code.
I see that I could revert back to a mongoose version like 3.9 that doesn't include the code in this screenshot but it still confuses me how this started to be flaky one day whereas it used to work perfectly fine on the same versions.
Here is roughly how I write my .create()
await Repayment.create({
userId: user._id,
isAutopay: true
});
Any ideas on how I can fix? Thanks!
screenshot is here
I'm working on integrating One-Signal with react native,
I followed One-Signal Docs.
now when I try to build on my iOS simulator I recieve this error:
OneSignal-inAppMessageClicked is not a supported event type for
RCTOneSignalEventEmitter. Supported events are: OneSignal-
remoteNotificationReceived, OneSignal-remoteNotificationOpened,
OneSignal-idsAvailable, OneSignal-emailSubscription
On the actual device everything seems to work.
My package.json:
"dependencies": {
"react": "16.8.3",
"react-native": "^0.59.9",
"react-native-onesignal": "^3.3.0",
}
This was a bug in the SDK that has since been fixed.
I'm getting these errors even with new versions of SDK:
2022-03-03 08:48:11.130
[error][tid:com.facebook.react.OneSignalQueue][RCTEventEmitter.m:78]
OneSignal-inAppMessageWillDisplay is not a supported event type for
RCTOneSignalEventEmitter. Supported events are:
...
[error][tid:com.facebook.react.OneSignalQueue][RCTEventEmitter.m:78]
OneSignal-inAppMessageWillDismiss is not a supported event type for
...
[error][tid:com.facebook.react.OneSignalQueue][RCTEventEmitter.m:78]
OneSignal-inAppMessageDidDismiss is not a supported event type for
RCTOneSignalEventEmitter. Supported events are:
...
[error][tid:com.facebook.react.OneSignalQueue][RCTEventEmitter.m:78]
OneSignal-inAppMessageDidDisplay is not a supported event type for
RCTOneSignalEventEmitter. Supported events are:
OneSignal-permissionChanged, OneSignal-subscriptionChanged,
OneSignal-notificationWillShowInForeground,
OneSignal-remoteNotificationOpened, OneSignal-inAppMessageClicked,
OneSignal-emailSubscriptionChanged,
OneSignal-smsSubscriptionChanged
I have the current version installed:
"react": "17.0.2",
"react-native": "0.62.2",
"react-native-onesignal": "^4.3.7",
Is there any way to workarround these errors?
On NodeJS with TypeScript and using npm request-promise (which wraps npm request).
I want to use the "time" option to time the round-trip as documented here "time - If true, the request-response cycle (including all redirects) is timed at millisecond resolution, and the result provided on the response's elapsedTime property" and which is available within the npm as evidenced here
if (options.time) {
self.timing = true
self.elapsedTime = self.elapsedTime || 0
}
But this option doesn't appear to be supported in any of the request definitions I can find.
So my first question is - am I reading things wrong?
If not, my second question is - is there a reason it's not there?
Finally, if it should be there - I can modify my local copy of the definitions but, of course, the better way is to get the repository definitions fixed and I'm just not exactly sure the best way to go about doing that, so who can point me in the right direction?
The definition for the time option is missing from the typings definition of the request package: https://github.com/louy/typed-request/blob/master/index.d.ts
The typings definition are for version 2.69 of the request package (https://github.com/typings/registry/blob/master/npm/request.json) which probably didn't have that time option
To get the repository definition fixed, you can ask the author of the type-request repository to fix it, or you can fork the main repository, do your updates and issue a pull request to the original author.
In the mean time, you can still install the definitions you updated into your project with:
typings install --save github:<YourGithubUsername>/<RepositoryName>#<CommitSha>
G'day all,
I've been having trouble upgrading to a more recent version of the ember-simple-auth module.
In particular I seem to have two challenges:
1) the application no longer transitions to the desired route after authenticating. the configuration looks like this:
ENV['ember-simple-auth'] = {
crossOriginWhiteList: ['http://10.10.1.7:3000'],
routeAfterAuthentication: 'profile',
//store: 'simple-auth-session-store:local-storage',
//authorizer: 'simple-auth-authorizer:token',
};
but it never gets to "profile".
2) I can't get the authenticated session to stick after a reload. I had been trying to use the local-store which I believed would do the trick, but it's not. Has something changed in the implementation?
The documentation seems to indicate that the configuration strings are right, but the transition and session store don't seem to be working.
Has anyone had a similar problem?
Thanks,
Andrew
you could try adding "routeIfAlreadyAuthenticated" to ENV['ember-simple-auth'] - or you could transition manually in index route "afterModel" hook, if session is already authenticated
have you configured a session store? https://github.com/simplabs/ember-simple-auth#session-stores - the way it's configured changed in 1.0, now you can add the desired session store to app/session-stores/application.js - maybe this solves #1 too.
OK. As the comments call out, there were two problems here:
1) I had written a customer authorizer for the old version of simple-auth which didn't work with the new version, and
2) I had a typo in the adapter code, where DataAdapterMixin was DAtaAdapterMixin.
Removing (1) and fixing (2) fixed the problem.
i'm using the request module to fetch image from website and pipe it into local file, the code is like:
url = http:/xxx.com/x.jpg;
if(url){
request(url).pipe(localFilePath);
}
if(xxx){
// save the localFilePath to db;
redirect('/index');
}
// The question is the filePath is needed in the index page, so if the file has not downloaded yet, then it can not show the file on index page.
i tried.
request(url).pipe(...).on('end',function(){
....
});
but it seems does't work..
so, i wonder how to do like :
yield xxxxx in node v0.11.x to pause the process until the file is already downloaded completely?
thanks
Yield is only presently available in Node 0.11 (when using the –harmony flag), but this is an unstable release that is probably not suitable for any kind of production use. Node 0.12 shouldn’t be too far away though, as 0.11 has been in development for a while now. So the good news is generators will be available in a stable Node.js release near you very soon!
If you want to stick with 0.10.x you will have to use callbacks or promises for now.