Skip to content
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

Closed
xaviergonz opened this issue May 5, 2019 · 3 comments
Closed
Labels
kind: feature New feature or request

Comments

@xaviergonz
Copy link

xaviergonz commented May 5, 2019

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:

{
 "extends": "../tsconfig.json",
 "include": ["."]
}

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

@xaviergonz
Copy link
Author

xaviergonz commented May 6, 2019

Ok, apparently as of v0.5.7 decorators do work for tests and builds, but vscode complains when they are used inside tests

@xaviergonz
Copy link
Author

One way I found to fix this was including the following tsconfig.json inside the tests folder

{
  "extends": "../tsconfig.json",
  "include": ["."]
}

@xaviergonz xaviergonz changed the title experimental decorators support for tests vscode doesn't use tsconfig.json settings for files in test folder May 6, 2019
@agilgur5
Copy link
Collaborator

I think #225 ended up duplicating this and #226 fixed it in the templates. Though this is a great workaround

@agilgur5 agilgur5 added the kind: feature New feature or request label Sep 6, 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
Labels
kind: feature New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants