Repository navigation
v3.7.2 not compiling valid Javascript #35149
Description
// test.js
function something({one} = {}) {}
$ tsc -v; tsc test.js --allowJS --checkJS --noEmit
Version 3.7.2
test.js:2:21 - error TS2525: Initializer provides no value for this binding element and the binding element has no default value.
2 function something({one} = {}) {}
~~~
Found 1 error.
Activity
kroleg commentedon Nov 17, 2019
Your javascript is not exactly "valid". If you remove --checkJS param it will comile without errors
fatcerberus commentedon Nov 17, 2019
checkJsmeans you’re type-checking it exactly like a.tsfile, just without type annotations. Any type inference semantics and errors that apply to TS code also apply tocheckJs’d JavaScript. This is, in fact, a type error because you’re trying to destructure aoneproperty out of a type ({}) which is known statically not to have it.AnyhowStep commentedon Nov 17, 2019
It worked out of the box and told you there was something suspicious it sniffed from your code.
milesj commentedon Nov 17, 2019
Bruce Pascoe (@fatcerberus) Vitaliy Zaytsev (@kroleg) answered your question above.
something({one} = {})is valid JS but not valid TS, and when you pass--checkJS, it validates your code as if it was TS.Are you purposefully ignoring everyones answer here?
kroleg commentedon Nov 17, 2019
dave-dm there is something suspicious. By default TS treats all object properties as required, so in case of
something({one} = {})oneis missing in{}.One solution will be to add jsdoc to tell TS that
oneis optional:Another is to add
ts-ignoredirectiveapalaniuk commentedon Nov 17, 2019
I doubt it strictly has to do with type checking via inferred types (if it was, I think you'd see
Property 'one' does not exist on type '{}'. ts(2339)) instead):All equally suspicious/statically verifiable, with the same inferred types. In fact, checking the same file contents in a
.tsfile and the most permissive tsconfig results ints(2339)for all the above cases (save for the no-default-value case), so it seems the claim thatcheckJsenforces the same checks as in.tsfiles using the same inferences isn't correct. It's not as though there haven't been similar apparent issues in the same ballpark before, which is a vaguely similar case, so I don't think it's unreasonable to be a bit surprised at this behaviour, or for it to be dismissed so readily.fatcerberus commentedon Nov 17, 2019
Maybe so, but the point remains: TS only promises it will compile JS out of the box (which it does—it even emits code in the presence of type errors!), it doesn’t promise it will typecheck.
checkJsisn’t just a “Verify the JSDoc” mode, it also attempts to infer types and verifies those too. It’s not even clear in many cases where the explicit documentation ends and the inferences begin.We’ll just have to wait to see what a TS team member has to say about this, but I still suspect this is by design.
AnyhowStep commentedon Nov 18, 2019
I think (maybe talking out of my ass?) there's also some stuff that TS only does syntactically, and not semantically for
checkJs.So, some constructs give errors because TS can identity the problem syntactically (someone specifically coded a check for it, that looks at the syntax only).
While other constructs (that express the same thing) don't give errors because the check can't just be done syntactically (or no one coded the syntax-only check).
checkJsis an overall more relaxed mode that doesn't always perform all checks.RyanCavanaugh commentedon Nov 26, 2019
If you just want to validate that your JS Doc matches your parameter names,
checkJswould be the wrong thing - it is for doing much more than that.typescript-bot commentedon Nov 28, 2019
This issue has been marked 'Working as Intended' and has seen no recent activity. It has been automatically closed for house-keeping purposes.