-
-
Notifications
You must be signed in to change notification settings - Fork 158
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cannot set property trace of #<Object> which has only a getter #196
Comments
Also been having this issue on |
This must be related to the v1.9.0 version just released - you can downgrade to v1.8.1 to avoid this. Can you provide a standalone example to reproduce the issue though? I'm not sure exactly what would cause this. |
@pimterry thanks, that was it |
@designamx this is clearly still an issue in the package, but glad to know the downgrade resolves this for you. Can you please share an example to help reproduce this, or any more information you can about how you're using loglevel? Otherwise this isn't going to be resolved in future releases of the package and so you'll just hit the same issue again later on. |
sure, I can do that |
I have placed a small docker project, to replicate you just need to Please let me know if there is anything else I can help with |
Thanks @designamx, that's perfect. Looks like it's something to do with ts-node-dev's ESM emulation, which treats the exported properties as unmodifiable. That is true for pure ESM modules, but this package isn't actually ESM at all, I think it's just that the runtime is effectively emulating that. You can fix this failure in the current version by importing with That said, I think I know what's caused the underlying issue in this case, so it should be easy enough to fix properly so everything works in the previous syntax too. I'll dig into that and release a fully fixed update shortly. |
Now fixed in v1.9.1. I've tested in the above repo and using the latest package version everything once again works correctly with no changes required to imports or anything else. I'm going to close this now as resolved, but please shout if anybody is still seeing this issue elsewhere. |
We previously ran the `test/type-test.ts` test through the TypeScript compiler to catch type issues, but there are more subtle problems that can happen at runtime with tools like `ts-node` (and maybe things like Deno, too -- I haven't tested that). This additionally *runs* the test file to make sure it doesn't throw at runtime, which would have caught issues like pimterry#196 ahead of time.
starting today we are getting this error
Node:
node:20.6.1-alpine3.17
also testednode:20.10.0-alpine3.17
The text was updated successfully, but these errors were encountered: