feat: support tsconfig references #4689
Conversation
sushruth
force-pushed
the
sushruth/feat-support-tsconfig-references
branch
2 times, most recently
from
3644197 to
c2eee48
Compare
|
Would you pls add some tests for this change? |
|
@ahnpnl Absolutely. That is the reason I have left it in draft stage. Thanks. |
sushruth
force-pushed
the
sushruth/feat-support-tsconfig-references
branch
from
c2eee48 to
daec5b7
Compare
|
@ahnpnl I added an e2e test case covering the tsconfig project references scenario. Please check it out when you can. Thanks! |
| @@ -218,6 +216,9 @@ export class ConfigSet { | |||
| this._matchTestFilePath = globsToMatcher( | |||
| this._matchablePatterns.filter((pattern: string | RegExp) => typeof pattern === 'string') as string[], | |||
| ) | |||
|
|
|||
| this._setupConfigSet(options) | |||
There was a problem hiding this comment.
_setupConfigSet now depends on matchablePatterns to exist when its called, because isTestFile is used in finding the appropriate tsconfig reference project to use for ts compile/transpile process.
There was a problem hiding this comment.
If we only check for test files, would it be like exceptional case when processing a random file? Should we also treat any files given through process method in transformer class similarly like this implementation?
There was a problem hiding this comment.
When processing a random file, it defaults to the current behavior - finds a relevant tsconfig.json to pick, as it currently does.
There was a problem hiding this comment.
Does it mean the handling with project reference config only applies to test files as you mentioned the file name needs to pass the check isTestFile?
There was a problem hiding this comment.
Yes, the rationale is - if there is a specific tsconfig project reference that addresses jest files alone, we should use that tsconfig file. Otherwise we default to current behavior of using the root tsconfig.json file we found.
There was a problem hiding this comment.
I wonder if this can break any existing behaviors? In theory, it should fix instead of breaking.
In reality, this actually changes the existing behavior into a different behavior. Do you think that is a breaking change since we changed the behavior? I still suspect there might be edge cases where this change can cause a breaking change.
| @@ -790,7 +790,6 @@ describe('_resolveTsConfig', () => { | |||
| expect(conf.options.configFilePath).toBeUndefined() | |||
| expect(findConfig).not.toHaveBeenCalled() | |||
| expect(readConfig.mock.calls[0][0]).toBe('/foo/tsconfig.bar.json') | |||
| expect(parseConfig).not.toHaveBeenCalled() | |||
There was a problem hiding this comment.
this will now be called to find out if we there are project references in the tsconfig to check.
| @@ -918,7 +917,6 @@ describe('_resolveTsConfig', () => { | |||
|
|
|||
| const conf = cs.parsedTsConfig | |||
| expect(conf.options.path).toBe(tscfgPathStub) | |||
| expect(findConfig).not.toHaveBeenCalled() | |||
There was a problem hiding this comment.
this will now be called to find out if we there are project references in the tsconfig to check.
Summary
Fixes #1648 -
isTestFile()check.isTestFile()check.Test plan
TODO
Does this PR introduce a breaking change?
Other information