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

Report diagnostics only on certain files [WIP] #701

Merged
merged 9 commits into from
Jan 20, 2018

Conversation

freeman
Copy link
Contributor

@freeman freeman commented Dec 23, 2017

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 the formatErrors 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)

@johnnyreilly
Copy link
Member

Initially this looks good to me. I'm on my mobile and so it's hard to do a proper review. Couple of things:

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 ?

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?

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)

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)
Copy link
Member

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sure will do

@freeman
Copy link
Contributor Author

freeman commented Dec 23, 2017

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?

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).

@freeman
Copy link
Contributor Author

freeman commented Dec 23, 2017

Seems complete. But I am having second thoughts about the option name.

reportFiles is nice because it is the same as at-loader (so moving between loader is easier). But I feel like ignoreFiles would be more coherent with ignoreDiagnostics. I am happy to change it if you prefer the ignoreFiles list approach.

@johnnyreilly
Copy link
Member

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.

@johnnyreilly
Copy link
Member

johnnyreilly commented Dec 24, 2017

I've fixed (I think) the broken validateLoaderOptionNames test with this: freeman#1

@@ -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.
Copy link
Member

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.

Copy link
Contributor Author

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 => {

Copy link
Member

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

Copy link
Contributor Author

@freeman freeman Dec 29, 2017

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)

@johnnyreilly
Copy link
Member

johnnyreilly commented Dec 24, 2017

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 reportFiles option. noEmitOnError in our tsconfig.json will allow us to detect if we're ignoring files correctly.

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

See also: https://github.com/TypeStrong/ts-loader/blob/master/test/execution-tests/2.0.3_typesResolution/test/app.tests.ts

So in your case the test need be no more complex than expect(1).toBe(1);. In order that the test pack passes it needs to contain a single passing test. In your scenario the actual test is arbitrary - the real test is than we compile without erroring with reportFiles in place. (in a situation where it would error without reportFiles filtering)

@freeman
Copy link
Contributor Author

freeman commented Dec 28, 2017

I will try the execution test approach

@freeman
Copy link
Contributor Author

freeman commented Dec 28, 2017

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 ...

@johnnyreilly
Copy link
Member

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 reportFiles. I think that would likely make things more complicated than they need be (and might introduce other issues) so a comparison test is fine.

@johnnyreilly
Copy link
Member

This all looks good - thanks for your work @freeman! I'm currently shepherding through a very complex PR from one of the TypeScript team: #685

That's a biggie so I'm holding off merging other PRs until that's in. Once that's in I'll look to merge and release. Watch this space!

@johnnyreilly
Copy link
Member

Tests aren't passing after other PRs were merged; I'm going to merge this and fix up afterwards

@johnnyreilly johnnyreilly merged commit ea8dfd7 into TypeStrong:master Jan 20, 2018
@johnnyreilly
Copy link
Member

Will look to release this with 3.3

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants