When I run my code with node 0.10.26, I'm getting an 'illegal access' error when using ES6 proxies. It doesn't happen with node 0.11.14
Any ideas how I can try to approach this? There's no stack trace.
I have a pretty convoluted proxy implementation, I've implemented the following methods:
get, set, has, hasOwn, delete, keys, enumerate, getOwnPropertyNames, getPropertyNames, getOwnPropertyDescriptor, getPropertyDescriptor
Is there a Proxy test suite set I can throw at it to see if I've implemented something incorrectly? Or any other way to see the source of the problem? I don't even know how to invoke half of the things I implemented :)
Any libraries that I can replace the Proxy object with? I think I saw one before but can't find it now.
EDIT: more details I forgot: It's not that there's no stack track, there's a stack trace from bluebird promise and it begins with Promise$_rejectPromises, which makes me think the error is related to this problem but I still don't know how find the source error with the problematic property.
So while looking for a Proxy replacement, I stumbled onto this thread, which says that this problem happens when something tries to use JSON.stringify() on the proxy.
I'm happy to say that implementing my own toJSON() method on the proxy object solved the problem.
Ahhh... so good to be back to 0.10.26
Related
I recently completed making an asynchronous version for all the functions in a pure C API, wrapped with N-API to work with JS/TS as a nodejs addon.
The last problem I had to fix was making sure that C POSIX-style errors (ie, returned integer codes) were transferred correctly to the JS at the end of a worker's execution (with the corresponding string, for which we have both an enum of exceptions, and a list of error messages).
When thrown with napi_throw_error (as I did for the synchronous version of all our calls), within the napi_async_complete_callback, these exceptions were never caught at the JS level (I suppose it was because it was within a different async context; I saw online people having a similar problem with ajax). Instead, I opted to just construct my errors as napi_value types, and return these via napi_reject_deferred. This seemed to have the desired effect, of being caught properly when doing a try { await My_NapiWrapper_XYZ() } catch (ex) { ... }.
So I don't really have a problem to fix, but I AM intrigued. These napi_throw_error thrown errors do probably go somewhere. Though I have no idea where. Where should one look to catch an error thrown with napi_throw_error from a napi_async_complete_callback ? Can you give a code example ?
No, they don't go anywhere. It is a bug that I just opened with them:
https://github.com/nodejs/node/issues/41377
There is a general problem with handling exceptions in asynchronous callbacks. Normally, they cannot be catched and should lead to program termination but Node's developers have decided to try to keep it running when they can.
I'm pretty new to typescript and I faced the issue with extending the Request type. I actually found a solution, but it doesn't feel right to me, and seems like there might be a better way.
First, the structure. I have a middleware checkAuth that checks the Bearer token, finds the user in the database (or creates one, in case it's the first time) and adds user to the req variable.
Most people recommend modifying the Express' Request type with custom declarations. I don't like this idea, because that will put user object into all requests, even before I actually save user into req.
Another solution is what I use now:
interface ReqWithUser extends Request {
user?: {
...
}
}
This allows me to declare req: ReqWithUser. But there's a flaw. When I try to access req.user, typescript is telling me that it's possibly undefined. Well, that's exactly what I declared with user?:. If I don't put a question mark there, then typescript is mad in router, saying Property 'user' is missing in type Request. That's fair. One of the solution is to use req!.user. Solves all problems, but it still feels imperfect to me. I know the req.user is there, it's not optional, otherwise checkAuth would fail and return 401. If it didn't, the user is there. What feels like the right solution is somehow modify the req type after the checkAuth middleware. Because that's when user is added into the req. Is it possible?
The issue has nothing to do with your types, but it's the fact that Express will always emit Request and not RequestWithUser.
So in your middleware function, you will always get a Request. The only reason RequestWithUser is acceptable is because you made it optional.
Truth is the middleware / decorator pattern doesn't work that well with express. You have a few options (some of which you mentioned)
Use declaration merging to 'patch' the built-in Request. You already mentioned you don't like this though, because it's a bit of a hack.
Don't use Express' middleware system and instead write something that understands how types change with decorators. I don't know exactly what this looks like, or if this has been done before.
Whenever you want to use RequestWithUser in your controllers/middlewares start off with an assertion function to ensure that user exists (allowing you to make it non-optional).
Cast to RequestWithUser, when you need it.
All these options have drawbacks:
You don't like for the reasons mentioned. It's not always 'accurate' so you are sort of lying to Typescript for convenience.
Sounds hard to do
Requires the use of an assertion function, which means you need to do a little extra work every time you want to use the user property. This work is not needed because you as developer know.
You probably don't like casting for the same reason you don't like to use declaration merging.
By far I think 2 is the best solution, because it gives you the advantage of typing without any hacks and without having to do the extra work of an assertion function (which happens during runtime). But it means abandoning Express' Middleware system. I wouldn't know exactly how to write this code, but I am curious how if it can be done...
FYI I opened another stack overflow question, because I am curious:
Typescript typing for decorator middleware patterns
Why is nodejs silently failing on an undeclared variable? It doesn't say anything, no stack trace, etc. This is the worst situation for debugging.
How do I get it to be noisier like any other language?
This is a little command-line utility written in nodejs. It's not a web app like most people are making. I'm fine with that. It's working as expected and I'm happily porting code over and everything works nice except when I make a typo and then it silently fails.
// Typo: should be var or const foo but I missed it and I want nodejs to error about it like any other language
foo = func();
I got a hint somewhere that promises are silencing errors like this. If so, why, and is there a workaround, preferably to make it die loudly.
Thanks
Shoot me. I missed logging the result of a promise rejection higher up. Once I put that in I started seeing the error and stack trace which was very helpful.
If I remember to log all rejection errors this will be fine.
The magic bit is that promises will use exceptions and send them to the rejection handler as the result object automatically.
This question+answer was helpful:
https://stackoverflow.com/a/46512164/3727869
I'm using sinon to stub an instance of express-Request.
It looks something like this:
let req = sinon.createStubInstance(Request);
My method accepts req: Request but my IDE complains about me using SinonStubbedInstance<Request> rather than Request.
I've tried using req as Request but I still get a warning about 'may be a mistake' and that I should first cast to unknown and only then to Request.
I actually don't need anything from this parameter so I really just want to stub it quickly and easily.
When using it in the call to your method, just cast it:
myMethod(req as any);
I understand that this was posed 3 years ago, but since the only answer given is wrong, I feel obliged to comment, for someone else might benefit from it.
It's strongly discouraged to use as any and your compiler should complain about this (unless you have a very good reason not to, you should use strict compiler option).
Casting to unknown and then to your type seems unintuitive, but it is a cleaner way than casting to any. If you use any you might be better off not using typescript at all.
https://www.typescriptlang.org/docs/handbook/declaration-files/do-s-and-don-ts.html#any
Consider doing
let req: SinonStubbedInstance<Request> & Request = sinon.createStubInstance(Request);
instead.
P.S.: Also, the use of let seems suspicious (sure cannot use const?), but that's a different topic.
If I create my httpBuilder as shown below (assume that a proxyUsername IS set, so setCredentials is called), then calls to httpAddress-es that are passed in properly are routed through the proxy. However, the Application has some http calls that are within the local network. Can http.nonProxyHosts be used to work around this and bypass the Proxy? If so, how? Use System.setProperty? Or something on HttpBuilder?
HTTPBuilder httpBuilder = new HTTPBuilder(httpAddress)
httpBuilder.setProxy(webProxyHost, webProxyPort, webProxyProtocol)
if (proxyUsername) {
httpBuilder.client.getCredentialsProvider().setCredentials(
new AuthScope(webProxyHost, webProxyPort),
new UsernamePasswordCredentials(proxyUsername, proxyPassword))
}
}
In the code above, all of the various named elements (webProxyHost, etc) are declared as String and set accordingly.
In answer to the question in the above comment, our primary 'nonProxyHost' need was for 'localhost' which is there by default. Thus this ceased to be an issue. Did not ever really find out how to accomplish this as it is somewhat version-specific on HttpClient.
You can set the System property:
System.setProperty('http.nonProxyHosts', myNonProxyHosts)
However, if you call 'setProxy' on HttpBuilder, even if you call 'useSystemProperties' it will not. This is in their documentation, just not obvious!
Finally, you might be able to call:
httpBuilder.client.params.setParameter('http.nonProxyHosts', myNonProxyHosts)
But I do not know for sure if that is the property name and documentation of those properties is hard to find. Worse - those 'params' are deprecated - you are supposed to use the better 'config' classes, though once again finding comprehensive documentation on all the parameters for that is not the easiest! Wish I could have been of more help!