Difference between how Svelte and JS imports from node_modules are handled

[dummdidumm]

Through #1048, I noticed there is a difference between how JS and Svelte files imported from node_modules are handled:

• Imports from node_modules that have no accompanying type definition (d.ts file) are marked as any which errors on strict mode (no implicit any). This means TS does not attempt to aquire the type structure from the node_modules package and also does not type-check it
• Svelte imports from node_modules are read and treated as a regular file inside the project. This means they don't need a accompanying type definition and their types are aquired, which can be good or bad depending on the quality of the Svelte file. Some libraries like svelte-loading-spinners take advantage of this and provide TS-versions of Svelte files as types, which is dangerous.

I think in the long run it would be best to align with the behavior of TypeScript here. This would probably a breaking change to some users which do deep imports of Svelte files within libraries which don't have a .svelte.d.ts next to them. I'm also not sure how to even achieve this as I thought this stuff is handled inside ts.resolveModuleName. As an intermediate step, we definetly need to stop type-checking stuff inside node_modules (also see #1100)
@jasonlyu123 thoughts?

[cor]

Is there a possible workaround for this in the meantime? It's hard to take advantage of svelte-check when the error list is polluted by dependencies.

[dummdidumm]

If you don't use the --tsconfig setting it should only check Svelte files that you tell it to. But that won't check JS/TS files or files or transitive files anymore.

[cor]

So I currently have two options:

1. Check both .svelte and .ts files, with the error list polluted by dependencies
2. Only check .svelte files, .ts files remain unchecked

Correct?

[dummdidumm]

Yes. You could check .ts files with tsc --noEmit however. But that might produce some false positives, depending on whether or not you have named imports from Svelte files inside TS files.

[probablykasper]

Is there any workaround for this yet, or are the only two options what @cor mentioned?

[dummdidumm]

Could you specify what your problem is? Files inside node_modules shouldn't get diagnosed anymore.

[probablykasper]

I'm running svelte-check --tsconfig ./tsconfig.json and it's showing errors/hints from node_modules:

Logs

> @ check /Users/kasper/dev/git/kryp
> svelte-check --tsconfig ./tsconfig.json


====================================
Loading svelte-check in workspace: /Users/kasper/dev/git/kryp
Getting Svelte diagnostics...

/Users/kasper/dev/git/kryp/node_modules/@tauri-apps/api/helpers/event.ts:7:1
Error: This import is never used as a value and must use 'import type' because 'importsNotUsedAsValues' is set to 'error'. 

import { WindowLabel } from '../window'
import { invokeTauriCommand } from './tauri'


/Users/kasper/dev/git/kryp/node_modules/@tauri-apps/api/event.ts:15:1
Error: This import is never used as a value and must use 'import type' because 'importsNotUsedAsValues' is set to 'error'. 
import { transformCallback } from './tauri'
import { LiteralUnion } from 'type-fest'



/Users/kasper/dev/git/kryp/node_modules/@tauri-apps/api/helpers/os-check.ts:8:20
Hint: 'appVersion' is deprecated. 
function isLinux(): boolean {
  return navigator.appVersion.includes('Linux')
}


/Users/kasper/dev/git/kryp/node_modules/@tauri-apps/api/helpers/os-check.ts:12:20
Hint: 'appVersion' is deprecated. 
function isWindows(): boolean {
  return navigator.appVersion.includes('Win')
}


/Users/kasper/dev/git/kryp/node_modules/@tauri-apps/api/helpers/os-check.ts:16:20
Hint: 'appVersion' is deprecated. 
function isMacOS(): boolean {
  return navigator.appVersion.includes('Mac')
}


/Users/kasper/dev/git/kryp/src/lib/NumericInput.svelte:36:9
Error: Object is possibly 'null'. (ts)
      } else {
        start -= 1
        end -= 1


/Users/kasper/dev/git/kryp/src/lib/NumericInput.svelte:37:9
Error: Object is possibly 'null'. (ts)
        start -= 1
        end -= 1
      }


====================================

[dummdidumm]

The diagnostics you get from node_modules are from real TypeScript files. These files will be type-checked by TypeScript/tsc, too. You can try yourself by doing import { emit } from '@tauri-apps/api/event' in a .ts file and then running tsc --noEmit. There's also an issue about this in the TypeScript repo, with the current conclusion that this is "works as designed": microsoft/TypeScript#40426. This sounds more like a misconfiguration of the build step of the library (why are .ts files deployed?) or a misuse of the library (avoid importing the .ts files).

[vpalos]

The diagnostics you get from node_modules are from real TypeScript files. These files will be type-checked by TypeScript/tsc, too. You can try yourself by doing import { emit } from '@tauri-apps/api/event' in a .ts file and then running tsc --noEmit. There's also an issue about this in the TypeScript repo, with the current conclusion that this is "works as designed": microsoft/TypeScript#40426. This sounds more like a misconfiguration of the build step of the library (why are .ts files deployed?) or a misuse of the library (avoid importing the .ts files).

It's not necessarily a misconfiguration to have *.ts files published in dependencies, right? Perhaps we're used to see .js+.d.ts files more often, but I see no problem in publishing libraries with *.ts files (even exclusively).

Also svelte-check is a tool to check for errors, while tsc is a compiler; therefore while it might be reasonable for tsc to go into all dependencies and show all errors by design, for svelte-check it seems more natural to have the option to exclude dependencies, since the goal is to validate my own codebase, and having the results polluted by tens, even hundreds of errors from dependencies can be very bad, especially since fixing all those errors is completely out of scope.

Just my 2 cents. Excellent work btw!

[thelinuxlich]

Any workaround?