Report diagnostics only on certain files [WIP] #701

freeman · 2017-12-23T17:21:03Z

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 · 2017-12-23T17:34:46Z

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.

johnnyreilly · 2017-12-23T17:37:18Z

src/utils.ts

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


Could we merge the 2 filter statements in utils please? I'd only like to iterate the collection a single time if possible.

sure will do

freeman · 2017-12-23T20:45:26Z

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 · 2017-12-23T21:21:33Z

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 · 2017-12-23T22:13:13Z

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 · 2017-12-24T06:52:59Z

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

johnnyreilly · 2017-12-24T07:00:39Z

README.md

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


Could you add an example here please? Examples rule the world when it comes to docs in my experience.

I have added an example

johnnyreilly · 2017-12-24T07:09:21Z

src/utils.ts

 ): WebpackError[] {

    return diagnostics
        ? diagnostics
-            .filter(diagnostic => loaderOptions.ignoreDiagnostics.indexOf(diagnostic.code) === -1)
+            .filter(diagnostic => {
+


Could we lose this blank line please? Reminds me - must add prettier to ts-loader

done (and +1 to prettier)

johnnyreilly · 2017-12-24T07:15:22Z

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 · 2017-12-28T19:19:47Z

I will try the execution test approach

freeman · 2017-12-28T20:26:38Z

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 · 2017-12-29T04:57:23Z

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 · 2018-01-01T06:18:55Z

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 · 2018-01-20T22:33:35Z

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

johnnyreilly · 2018-01-20T23:47:26Z

Will look to release this with 3.3

initial implementation of reportFiles

2dae882

johnnyreilly reviewed Dec 23, 2017

View reviewed changes

freeman added 2 commits December 23, 2017 22:14

patterns are now relative to the webpack context

47f5765

add to README.md

4a674fa

johnnyreilly reviewed Dec 24, 2017

View reviewed changes

fix validateLoaderOptionNames test

71d3776

freeman added 2 commits December 29, 2017 10:09

formatting

3b20728

improve documentation

a0da49a

johnnyreilly added 3 commits January 20, 2018 21:59

Merge branch 'master' into reportFiles

64914e0

Add missing comma

27469c2

Merge in watch fixes

92a73e2

johnnyreilly merged commit ea8dfd7 into TypeStrong:master Jan 20, 2018

renovate bot mentioned this pull request Feb 2, 2018

chore(deps): update dependency ts-loader to v3.5.0 webcomponents/custom-elements-everywhere#223

Merged

This was referenced Mar 19, 2018

Bump ts-loader from 2.3.4 to 4.1.0 fcknutwil/sponsorencrm_client#48

Closed

Bump ts-loader from 3.2.0 to 4.1.0 Armour/express-webpack-react-redux-typescript-boilerplate#221

Closed

Bump ts-loader from 3.2.0 to 4.1.0 jamesabels/mithril-bp#91

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Report diagnostics only on certain files [WIP] #701

Report diagnostics only on certain files [WIP] #701

freeman commented Dec 23, 2017

johnnyreilly commented Dec 23, 2017

johnnyreilly Dec 23, 2017

freeman Dec 23, 2017

freeman commented Dec 23, 2017

freeman commented Dec 23, 2017

johnnyreilly commented Dec 23, 2017

johnnyreilly commented Dec 24, 2017 •

edited

Loading

johnnyreilly Dec 24, 2017

freeman Dec 29, 2017

johnnyreilly Dec 24, 2017

freeman Dec 29, 2017 •

edited

Loading

johnnyreilly commented Dec 24, 2017 •

edited

Loading

freeman commented Dec 28, 2017

freeman commented Dec 28, 2017

johnnyreilly commented Dec 29, 2017

johnnyreilly commented Jan 1, 2018

johnnyreilly commented Jan 20, 2018

johnnyreilly commented Jan 20, 2018

Report diagnostics only on certain files [WIP] #701

Report diagnostics only on certain files [WIP] #701

Conversation

freeman commented Dec 23, 2017

johnnyreilly commented Dec 23, 2017

johnnyreilly Dec 23, 2017

Choose a reason for hiding this comment

freeman Dec 23, 2017

Choose a reason for hiding this comment

freeman commented Dec 23, 2017

freeman commented Dec 23, 2017

johnnyreilly commented Dec 23, 2017

johnnyreilly commented Dec 24, 2017 • edited Loading

johnnyreilly Dec 24, 2017

Choose a reason for hiding this comment

freeman Dec 29, 2017

Choose a reason for hiding this comment

johnnyreilly Dec 24, 2017

Choose a reason for hiding this comment

freeman Dec 29, 2017 • edited Loading

Choose a reason for hiding this comment

johnnyreilly commented Dec 24, 2017 • edited Loading

freeman commented Dec 28, 2017

freeman commented Dec 28, 2017

johnnyreilly commented Dec 29, 2017

johnnyreilly commented Jan 1, 2018

johnnyreilly commented Jan 20, 2018

johnnyreilly commented Jan 20, 2018

johnnyreilly commented Dec 24, 2017 •

edited

Loading

freeman Dec 29, 2017 •

edited

Loading

johnnyreilly commented Dec 24, 2017 •

edited

Loading