-
Notifications
You must be signed in to change notification settings - Fork 1k
fix: derive files from tsconfigs which extend #4006
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
fix: derive files from tsconfigs which extend #4006
Conversation
🦋 Changeset detectedLatest commit: 04dbe7a The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
|
| const existingOptions: CompilerOptions = {}; | ||
| if (options.exclude !== undefined) { | ||
| (configFile.config.exclude ??= []).push(...options.exclude); | ||
| existingOptions.exclude = options.exclude; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you know for sure that this doesn't override the excludes in the config file? Maybe you should still concat the two?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i don't know for sure, but internally, that param is called existingOptions, and it is processed in https://github.com/microsoft/TypeScript/blob/9701f55f7217d7bd56d28e73b250444efcefa8dd/src/compiler/commandLineParser.ts#L2859
| packagePath /* basePath */, | ||
| undefined /* existingOptions */, | ||
| path.relative(packagePath, configFileName) /* configFileName */ | ||
| ts.sys, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would be nice to keep the comments I think 👀
|
as of a82b0e7, the analyzer picks up on my source files, but it does not seem to parse the tsconfig correctly. namely, I get a bunch of errors which i don't normally get with typescript, probably related to build mode errors |
this change reduced the number of errors when analyzing patternfly-elements from 152 to 79
|
By tweaking my monorepo project's tsconfigs i reduced the number of errors to 17, all of which appear to be rest of the errorsSo with that in mind i think this is ready for review |
|
Tagging in @kevinpschaaf and @rictic both for the review, but also... we need to think about supporting multiple versions of TypeScript. |
|
Just want to record here that declaration augmenting fixed the above errors, but I'm left with this, despite the corresponding declaration being in scope : |
|
I think that is because the analyzer is actually trying to find that file on disk. It should really give up if it can't. |
|
im still curious/mildly concerned of how the error got the analyzer explicitly passes a special lit error code, not could lead to confusion in future if other analyzer errors accidentally end up with typescript error codes... here we don't specify a |
|
here's my calling code: async function analyze(argv: Opts) {
const { packagePath } = argv;
const path = packagePath instanceof URL ? fileURLToPath(packagePath) : join(process.cwd(), packagePath);
const analyzer = createPackageAnalyzer(path as AbsolutePath, {
exclude: [
'**/*.spec.ts',
'**/*.e2e.ts',
'**/*.d.ts',
'**/*.js',
],
});
try {
const p = analyzer.getPackage();
console.log('got package', p);
} catch (e: any) {
if (Array.isArray(e.diagnostics)) {
console.log(e.diagnostics.at(0));
const formattedDiagnostics = formatDiagnostics(e.diagnostics);
console.log(`${formattedDiagnostics}\n${e.diagnostics.length} errors`);
} else {
console.group(`Analyzer error`);
console.error(e);
console.groupEnd();
}
}
}here is the diagnostic object from {
file: <ref *1> SourceFileObject { ... },
start: 566,
length: 21,
category: 1,
code: 2323,
messageText: 'Could not resolve specifier ./BaseAccordion.css to filesystem path.'
}entire diagnostic object |
|
all good @bennypowers , it turns out Peter already fixed it in #3866! non-issue 🥳 i guess it just hasn't been published yet |
| path.relative(packagePath, configFileName) /* configFileName */ | ||
| isDirectory ? packagePath : path.dirname(packagePath) /* basePath */, | ||
| {} /* existingOptions */, | ||
| configFileName /* configFileName */ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So, this whole API is really funky, but note early on I had left this comment:
lit/packages/labs/analyzer/src/lib/analyzer.ts
Lines 56 to 60 in 9a7b654
| // Note that passing `packageRoot` for `basePath` works, but | |
| // `getOutputFileNames` will fail without passing `configFileName`; once you | |
| // pass that, it looks like paths are relative to the `configFileName` | |
| // location (which is also under `packageRoot`), in which case `basePath` | |
| // shouldn't duplicate `packageRoot` |
I believe this empirical finding was why the configFileName argument here was being calculated relative to basePath. But I guess if you're not getting the errors I was having with packagePath show up both in basePath and configFileName and the tests are passing, I probably just misjudged what was going on...?
kevinpschaaf
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, with these changes I've confirmed I can generate a CEM from MWC[*] source, which besides the monorepo tests, was the other thing I had been testing analyzer against, so while I can't really explain why the comment I linked from the older code would seem to indicate this change would break something, it doesn't seem to.
So LGTM, and if we find out this breaks something we'll just need to add more tests.
*To get a successful run on MWC, I did need to upgrade the TS version the analyzer was using to match what MWC was using (per known issue in #4018), and then skip over a couple of unresolvable symbols in MWC code added since I last tested (needs more investigation, but wasn't the failure mode this type of change would lead to).
Fixes #3999