-
Notifications
You must be signed in to change notification settings - Fork 507
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
vscode doesn't use tsconfig.json settings for files in test folder #84
Labels
kind: feature
New feature or request
Comments
Ok, apparently as of v0.5.7 decorators do work for tests and builds, but vscode complains when they are used inside tests |
One way I found to fix this was including the following tsconfig.json inside the tests folder
|
xaviergonz
changed the title
experimental decorators support for tests
vscode doesn't use tsconfig.json settings for files in test folder
May 6, 2019
This was referenced Mar 24, 2020
Gnuxie
added a commit
to the-draupnir-project/Draupnir
that referenced
this issue
Feb 19, 2024
Ok so this is pretty shit, i hate the integration test suite now. The reason why we return the test functions with `as any` in the hello test is because we had to remove `Record<string, any>` from mocha's test context interface, otherwise the interface would have been completely useless. Maybe there is a ts setting though to not infer any from `this` at all? and just ignore those properties. The tsconfig.json situation is a bit weird, i don't understand why it's in this situation. However, it seems like we can try to jaredpalmer/tsdx#84 (comment) use this workaround so that ts language features work in the test directory. I think we should focus on doing as little effort as possible getting these tests into working condition. If something is too complicated, it will need removing. If we need to make additional tests, this entire integration tests directory should be moved to a legacy-integration directory and we can start afresh. We should also ideally not integration tests as much as possible and try to reuse the unit helpers from MPS. This is even going to be critical later on.
Gnuxie
added a commit
to the-draupnir-project/Draupnir
that referenced
this issue
Mar 1, 2024
Ok so this is pretty shit, i hate the integration test suite now. The reason why we return the test functions with `as any` in the hello test is because we had to remove `Record<string, any>` from mocha's test context interface, otherwise the interface would have been completely useless. Maybe there is a ts setting though to not infer any from `this` at all? and just ignore those properties. The tsconfig.json situation is a bit weird, i don't understand why it's in this situation. However, it seems like we can try to jaredpalmer/tsdx#84 (comment) use this workaround so that ts language features work in the test directory. I think we should focus on doing as little effort as possible getting these tests into working condition. If something is too complicated, it will need removing. If we need to make additional tests, this entire integration tests directory should be moved to a legacy-integration directory and we can start afresh. We should also ideally not integration tests as much as possible and try to reuse the unit helpers from MPS. This is even going to be critical later on.
Gnuxie
added a commit
to the-draupnir-project/Draupnir
that referenced
this issue
Apr 6, 2024
Ok so this is pretty shit, i hate the integration test suite now. The reason why we return the test functions with `as any` in the hello test is because we had to remove `Record<string, any>` from mocha's test context interface, otherwise the interface would have been completely useless. Maybe there is a ts setting though to not infer any from `this` at all? and just ignore those properties. The tsconfig.json situation is a bit weird, i don't understand why it's in this situation. However, it seems like we can try to jaredpalmer/tsdx#84 (comment) use this workaround so that ts language features work in the test directory. I think we should focus on doing as little effort as possible getting these tests into working condition. If something is too complicated, it will need removing. If we need to make additional tests, this entire integration tests directory should be moved to a legacy-integration directory and we can start afresh. We should also ideally not integration tests as much as possible and try to reuse the unit helpers from MPS. This is even going to be critical later on.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Current Behavior
When I set experimentalDecorators to true in tsconfig.json it works ok for files in "src", but it doesn't work for files in "test" (vscode marks decorators in red, but it works ok when running 'test')
Desired Behavior
When experimentalDecorators is set to true in tsconfig.json it should also be for vscode test files
Suggested Solution
Add a tsconfig.json file to the tests folder:
with any other overrides that might be needed to make tests work and make jest use that one.
Who does this impact? Who is this for?
Libs that use experimental decorators
Describe alternatives you've considered
N/A
Additional context
N/A
The text was updated successfully, but these errors were encountered: