-
-
Notifications
You must be signed in to change notification settings - Fork 431
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
Report diagnostics only on certain files [WIP] #701
Conversation
Initially this looks good to me. I'm on my mobile and so it's hard to do a proper review. Couple of things:
Yeah that's probably fine and if we're using something I definitely want to be explicit. How did we have it indirectly in the first place?
Yup absolutely fine. |
src/utils.ts
Outdated
@@ -49,12 +50,21 @@ export function formatErrors( | |||
loaderOptions: LoaderOptions, | |||
colors: Chalk, | |||
compiler: typeof typescript, | |||
merge?: { file?: string; module?: WebpackModule } | |||
merge: { file?: string; module?: WebpackModule } | |||
): WebpackError[] { | |||
|
|||
return diagnostics | |||
? diagnostics | |||
.filter(diagnostic => loaderOptions.ignoreDiagnostics.indexOf(diagnostic.code) === -1) |
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.
Could we merge the 2 filter statements in utils
please? I'd only like to iterate the collection a single time if possible.
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.
sure will do
It is karma that is installing it (so only a dev dependency which makes it even more important to add it to the direct dependencies). |
Seems complete. But I am having second thoughts about the option name.
|
There's a long standing plan (which may or may not happen) to merge ts-loader and ATL. As part of that we'd discussed standardising on the same API as we moved towards merging. For that reason I think going with the same option name as ATL is probably a good idea. |
I've fixed (I think) the broken |
@@ -245,6 +245,10 @@ messages are emitted via webpack which is not affected by this flag. | |||
You can squelch certain TypeScript errors by specifying an array of diagnostic | |||
codes to ignore. | |||
|
|||
#### reportFiles *(string[]) (default=[])* | |||
|
|||
Only report errors on files matching these glob patterns. |
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.
Could you add an example here please? Examples rule the world when it comes to docs in my experience.
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 have added an example
src/utils.ts
Outdated
): WebpackError[] { | ||
|
||
return diagnostics | ||
? diagnostics | ||
.filter(diagnostic => loaderOptions.ignoreDiagnostics.indexOf(diagnostic.code) === -1) | ||
.filter(diagnostic => { | ||
|
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.
Could we lose this blank line please? Reminds me - must add prettier to ts-loader
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.
done (and +1 to prettier)
Could we remove the comparison test you've implemented and replace it with an execution test please? https://github.com/TypeStrong/ts-loader/blob/master/test/execution-tests/README.md Execution tests are run against all versions of TypeScript that are supported and tend to be less flaky than comparison tests (which we only run against the latest supported version of TypeScript) My guess is you're going to want to implement broken code which will be ignored by use of the new A good basis for your test might be this one: https://github.com/TypeStrong/ts-loader/tree/master/test/execution-tests/2.0.3_typesResolution - it follows the same principles So in your case the test need be no more complex than |
I will try the execution test approach |
I don't think the execution tests approach can work because reportFiles (and ignoreDiagnostics) do not work at the typescript compiler level. They only filter errors from webpack reporting but if noEmitOnError is true, nothing will be emitted anyway. Not sure if it is possible to go one level deeper ... |
Yup - I think you're right. We could only use an execution test if we changed the approach so that the files being supplied to the Typescript compiler were varied by |
Tests aren't passing after other PRs were merged; I'm going to merge this and fix up afterwards |
Will look to release this with 3.3 |
Fixes #700
This is a first implementation heavily borrowed from at-loader.
I had to add an explicit
micromatch
dependency (even though we have it indirectly, I felt it was cleaner to have a dependency on it if we rely on it). Is that ok ?Also currently the pattern is applied against the fully qualified path to the file. I think we should match against the
context
relative path. Unfortunately it is not available in theformatErrors
function.I think it is reachable in every call site. Is adding a new argument to
formatErrors
OK ? (note that I already took a first step by making the last argument non optional as it was provided at every call site)