Fork-ts-checker-webpack-plugin: Parameter to define which files should be linted

[dreef3]

Hi,

Thanks for a great plugin! The issue I have is the following:

All files in the program are passed to TSLint for linting. However the program contains not only the files of the application but also any dependencies from node_modules. In my case I have some dependencies with *.ts files which are imported by application.

And while I definitely need them for compilation & type checking I'd prefer not to run TSLint on them.

Do you think it'be possible to have a param like skipLint which would accept string[] of regexp for files which should not be linted? By default it'd filter out node_modules.

[DorianGrey]

At least the ability to kick of the node_modules directory would be awesome - there are several cases where people are publishing their ts source files along with their transpiled counterparts to be used directly, or they referencing them in provided typings, so that they get picked up.

However, it should be documented that using to many filters here might cause this to become quite expensive.

Rough suggestion: Replace

https://github.com/Realytics/fork-ts-checker-webpack-plugin/blob/39d7986fe5c9a110aa21858d873540b05c106fce/src/IncrementalChecker.ts#L181-L183

with something like

// From configuration; these entries should be present by default
const skipped = [
        /\.d\.ts$/, // Replaces the current "endsWith" check
        /(\\|\/)node_modules(\\|\/)/ // Beware of path separator differences Windows / rest of the world
];
const filesToLint = this.files
        .keys()
        .filter(filePath =>
           !this.files.getData(filePath).linted && !skipped.some(s => s.test(filePath))
        ); 

[mdudek]

I'm facing same issue. I need to reference some *.ts files from node_modules, but some of these files are not tslint compliant. So i can't build my project without tslint errors at this moment.

There is an option in tslint.json that could be used for excluding of files from linting, but this setting is not respected by fork-ts-checker-webpack-plugin:

"linterOptions": { "exclude": [ "node_modules/**/*.ts" ] }

[DorianGrey]

That would be even better than a custom solution.

This option in the tslint.json currently seem to only be respected automatically when using the tslint CLI. Users of the Linter API have to do that manually.

[johnnyreilly]

Why not submit a PR? I've had a good level of success with PRs being taken by this fine project.

[DorianGrey]

Sure, I'll see if can get some spare time during the next days to work on this. Should not be that hard.

For reference - this is the approach tslint takes:
https://github.com/palantir/tslint/blob/5634a074f72bd82854bc5439a3a27388b05b64d3/src/runner.ts#L193-L196

Dealing with these options should attempt to follow this behavior and use the same tools, since it simplifies validation and minimizes additional dependencies.

[johnnyreilly]

Awesome!

[mdudek]

Great, could you release a new version to npm please?

[piotr-oles]

After rewriting it to typescript, deploy script won't work :/ I need time to fix it, I will try to do this today

[johnnyreilly]

Awesome!

[rhys-vdw]

Is there a way to use this plugin right now? When I build I get about 100 of these:

    ERROR in /Users/rhys/Projects/usability-hub/usability_hub/node_modules/@types/react-beautiful-dnd/node_modules/@types/react/index.d.ts
    (3535,13): Subsequent variable declarations must have the same type.  Variable 'a' must be of type 'DetailedHTMLProps<AnchorHTMLAttributes<HTMLAnchorElement>, HTMLAnchorElement>', but here has type 'DetailedHTMLProps<AnchorHTMLAttributes<HTMLAnchorElement>, HTMLAnchorElement>'.

    ERROR in /Users/rhys/Projects/usability-hub/usability_hub/node_modules/@types/react-beautiful-dnd/node_modules/@types/react/index.d.ts
    (3536,13): Subsequent variable declarations must have the same type.  Variable 'abbr' must be of type 'DetailedHTMLProps<HTMLAttributes<HTMLElement>, HTMLElement>', but here has type 'DetailedHTMLProps<HTMLAttributes<HTMLElement>, HTMLElement>'.

    ERROR in /Users/rhys/Projects/usability-hub/usability_hub/node_modules/@types/react-beautiful-dnd/node_modules/@types/react/index.d.ts
    (3537,13): Subsequent variable declarations must have the same type.  Variable 'address' must be of type 'DetailedHTMLProps<HTMLAttributes<HTMLElement>, HTMLElement>', but here has type 'DetailedHTMLProps<HTMLAttributes<HTMLElement>, HTMLElement>'.

    ERROR in /Users/rhys/Projects/usability-hub/usability_hub/node_modules/@types/react-beautiful-dnd/node_modules/@types/react/index.d.ts
    (3538,13): Subsequent variable declarations must have the same type.  Variable 'area' must be of type 'DetailedHTMLProps<AreaHTMLAttributes<HTMLAreaElement>, HTMLAreaElement>', but here has type 'DetailedHTMLProps<AreaHTMLAttributes<HTMLAreaElement>, HTMLAreaElement>'.

    ERROR in /Users/rhys/Projects/usability-hub/usability_hub/node_modules/@types/react-beautiful-dnd/node_modules/@types/react/index.d.ts
    (3539,13): Subsequent variable declarations must have the same type.  Variable 'article' must be of type 'DetailedHTMLProps<HTMLAttributes<HTMLElement>, HTMLElement>', but here has type 'DetailedHTMLProps<HTMLAttributes<HTMLElement>, HTMLElement>'.

    ERROR in /Users/rhys/Projects/usability-hub/usability_hub/node_modules/@types/react-beautiful-dnd/node_modules/@types/react/index.d.ts
    (3540,13): Subsequent variable declarations must have the same type.  Variable 'aside' must be of type 'DetailedHTMLProps<HTMLAttributes<HTMLElement>, HTMLElement>', but here has type 'DetailedHTMLProps<HTMLAttributes<HTMLElement>, HTMLElement>'.

    ERROR in /Users/rhys/Projects/usability-hub/usability_hub/node_modules/@types/react-beautiful-dnd/node_modules/@types/react/index.d.ts
    (3541,13): Subsequent variable declarations must have the same type.  Variable 'audio' must be of type 'DetailedHTMLProps<AudioHTMLAttributes<HTMLAudioElement>, HTMLAudioElement>', but here has type 'DetailedHTMLProps<AudioHTMLAttributes<HTMLAudioElement>, HTMLAudioElement>'.

    ERROR in /Users/rhys/Projects/usability-hub/usability_hub/node_modules/@types/react-beautiful-dnd/node_modules/@types/react/index.d.ts
    (3542,13): Subsequent variable declarations must have the same type.  Variable 'b' must be of type 'DetailedHTMLProps<HTMLAttributes<HTMLElement>, HTMLElement>', but here has type 'DetailedHTMLProps<HTMLAttributes<HTMLElement>, HTMLElement>'.

    ERROR in /Users/rhys/Projects/usability-hub/usability_hub/node_modules/@types/react-beautiful-dnd/node_modules/@types/react/index.d.ts
    (3543,13): Subsequent variable declarations must have the same type.  Variable 'base' must be of type 'DetailedHTMLProps<BaseHTMLAttributes<HTMLBaseElement>, HTMLBaseElement>', but here has type 'DetailedHTMLProps<BaseHTMLAttributes<HTMLBaseElement>, HTMLBaseElement>'.

[johnnyreilly]

Do you know when 0.2.9 might get released @piotr-oles? I know it's a bit tricky as you're depending on someone else but it would be great to get an idea...

Just a thought, if it's going to be a problem releasing new versions is it worth publishing this as a different package so you don't have this issue?

[johnnyreilly]

The 0.2.9 release has been slightly delayed for some fairly understandable reasons. If you're too impatient to wait for it to land on npm you could use this in the short-term: https://github.com/typestrong/fork-ts-checker-webpack-plugin

nb The repo above will be removed from GitHub once 0.2.9 is released to npm. This is just for those impatient people out there (well, me mostly :wink:)

[DorianGrey]

@rhys-vdw : These errors have nothing to do with this plugin in particular.
Considering that path

node_modules/@types/react-beautiful-dnd/node_modules/@types/react/index.d.ts

I'd assume that multiple versions of @types/react got installed, since these ones are nested, This happens quite often when using lockfiles (either from yarn or npm) in conjunction with wildcard dependency definitions (e.g."*"). I've often had this problem with @types/react-dom.

I currently only know of two ways to get rid of this:

• Explicitly dedupe installed dependency, thus getting rid of nested installations (e.g. via yarn install --flat) - setting this up might take a while, depending on your project's dependency list. IIRC, npm dedupe is easier to handle than its counterpart on yarn. Might be required to do this again when updating your dependencies.
• Removing node_modules, you lockfile and perform a clean install. Simpler, but might take even longer, depending on your dependency list. Might be required to do this again when updating your dependencies.

[rhys-vdw]

Interesting. I don't see these errors when running tslint from
command-line. I wonder what the difference is.

I can try to flatten the dependencies, but if it's a fragile solution then
it's not something I'd be comfortable merging into master.

On Sat, 18 Nov. 2017, 6:15 am Christian Linne, [e-mail]
wrote:

@rhys-vdw https://github.com/rhys-vdw : These errors have nothing to do
with this plugin in particular.
Considering that path

node_modules/@types/react-beautiful-dnd/node_modules/@types/react/index.d.ts

I'd assume that multiple versions of @types/react got installed, since
these ones are nested, This happens quite often when using lockfiles
(either from yarn or npm) in conjunction with wildcard dependency
definitions (e.g."+"). I've often had this problem with @types/react-dom.

I currently only know of two ways to get rid of this:

• Explicitly dedupe installed dependency, thus getting rid of nested
  installations (e.g. via yarn install --flat) - setting this up might
  take a while, depending on your project's dependency list. IIRC, npm
  dedupe is easier to handle than its counterpart on yarn. Might be
  required to do this again when updating your dependencies.
• Removing node_modules, you lockfile and perform a clean install.
  Simpler, but might take even longer, depending on your dependency list.
  Might be required to do this again when updating your dependencies.

—
You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub
https://github.com/Realytics/fork-ts-checker-webpack-plugin/issues/61#issuecomment-345338732,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAyLWaYRdmPNzk7wuh-GNI-gCl9bavNnks5s3dtHgaJpZM4QN7LQ
.

[johnnyreilly]

Do you get the same problem if you use https://github.com/typestrong/fork-ts-checker-webpack-plugin ? (Temporary 0.2.9 repo) I'm wondering if the tslint 0.2.9 changes resolve the problem

[DorianGrey]

Interesting. I don't see these errors when running tslint from
command-line. I wonder what the difference is.

This message is not generated by the linter, it's a TSC error. There are a couple of issues pending regarding this error.
E.g. - one specifically for @types/react (still applies for the most recent versions):
https://github.com/DefinitelyTyped/DefinitelyTyped/issues/18484
One from Microsoft's react starter project:
https://github.com/Microsoft/TypeScript-React-Starter/issues/89

Maybe the workaround mentioned in this will be of any help, until the true source of this issue gets fixed (as mentioned above - dependecy locking when wildcards are involved => also discussed in the linked thread).

[rhys-vdw]

Thanks @DorianGrey.