Type inference broken in JS files - Behavior differs from typescript

[jbwyme]

TypeScript Version: Version 3.3.3, Version 3.4.0-dev.20190220

Search Terms:
Object mutation, Inferred type, JSDoc

Code

// @ts-check

/** @returns {{prop: string}} */
function buildParams() {
  const params = {
    prop: `val`,
  };
  params.filter = {mutation: 1};
  return params;
}

buildParams();

Expected behavior:
Should error on object mutation and/or return type not matching

Actual behavior:
No errors

Example of bug

local:test$ cat test.js
// @ts-check

/** @returns {{prop: string}} */
function buildParams() {
  const params = {
    prop: `val`,
  };
  params.filter = {mutation: 1};
  return params;
}

buildParams();

local:test$ node_modules/typescript/bin/tsc --noEmit --allowJs test.js 

Proof that type checking works in general for js files

local:test$ cat test.js 
// @ts-check

/** @returns {{prop: string}} */
function buildParams() {
  const params = {
  };
  params.filter = {mutation: 1};
  return params;
}

buildParams();

local:test$ node_modules/typescript/bin/tsc --noEmit --allowJs test.js 
test.js:8:3 - error TS2741: Property 'prop' is missing in type '{ filter: { mutation: number; }; }' but required in type '{ prop: string; }'.

8   return params;
    ~~~~~~~~~~~~~~

  test.js:3:16
    3 /** @returns {{prop: string}} */
                     ~~~~
    'prop' is declared here.


Found 1 error.

Same logic in typescript

local:test$ cat test.ts
type Data = {
  prop: string,
}

function buildParams(): Data {
  const params = {
    prop: `test`,
  };
  params.filter = {mutation: 1};
  return params;
}

buildParams();

local:test$ node_modules/typescript/bin/tsc --noEmit test.ts
test.ts:9:10 - error TS2339: Property 'filter' does not exist on type '{ prop: string; }'.

9   params.filter = {mutation: 1};
           ~~~~~~


Found 1 error.

[RyanCavanaugh]

There are several intentional differences between JS and TS files as far as typechecking goes; this is one of them - you can "tack on" new properties to an object while in the same scope it was declared, i.e. this is still an error:

// @ts-check

/** @returns {{prop: string}} */
function buildParams() {
    const params = {
        prop: `val`,
    };
    return params;
}

const p = buildParams();
// Error
p.filter = { mutation: 1 };

[nojvek]

That's really confusing to be honest. Could you explain why this is working as intended. It clearly is not catching a bug one would expect typescript should. I would expect TS/JS typing to be functionally equivalent. Isn't that the whole value proposition?

Kind ask: At-least give us some sort of option/workaround to enable stricter js checking which is functionally equivalent to TS.

[RyanCavanaugh]

Could you explain why this is working as intended

There are several intentional differences between JS and TS files as far as typechecking goes; this is one of them - you can "tack on" new properties to an object. This was based on feedback of trying out the ts-check mode on many JS codebases.

At-least give us some sort of option/workaround to enable stricter js checking which is functionally equivalent to TS.

Certainly open to a new suggestion on that.

[jbwyme]

It seems like there might be two different fundamental use-cases in the @ts-check world: 1) A stop-gap for people who want to migrate to typescript but need to do it incrementally and 2) An alternative way to get type checking using vanilla JS. The decision to diverge in behavior from @ts-check and typescript makes sense when solving for use case #1. Would you say this is an accurate assessment? Is there a long-term vision that would support use case #2?

…

On Fri, Mar 1, 2019 at 10:29 AM Ryan Cavanaugh ***@***.***> wrote: Could you explain why this is working as intended There are several *intentional* differences between JS and TS files as far as typechecking goes; this is one of them - you can "tack on" new properties to an object. This was based on feedback of trying out the ts-check mode on many JS codebases. At-least give us some sort of option/workaround to enable stricter js checking which is functionally equivalent to TS. Certainly open to a new suggestion on that. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#30009 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAh_UmyYp1G9b3v5Zd2MZvuxaMfxIM1Fks5vSXGBgaJpZM4bGVb3> .

[typescript-bot]

This issue has been marked 'Working as Intended' and has seen no recent activity. It has been automatically closed for house-keeping purposes.

[tdumitrescu]

Really typescript-bot?

[jbwyme]

@RyanCavanaugh Should I create a separate issue to open up a discussion about the goals of typescript vs @ts-check? My concern is that if @ts-check is some weird subset of / divergent from typescript, it will not be usable as a replacement and will in fact result in a lot of unexpected behavior thus eliminating the utility of it.

[RyanCavanaugh]

I have to document this anyway so I'll start here - here are the differences in typechecking between JS and TS files:

• JS Doc will change the types of parameters/etc in JS files, but not in TS files
• The default type argument in a generic call with no inferences is any instead of {}
• Variables in JS always get control-flow initialization treatment instead of bare initializer treatment (in TS, this requires noImplicitAny to be on)
• Variables initialized with object literals are subject to expando treatment
• JS functions can be invoked with new in more cases
• Object literals in JS get a contextual this value (in TS, noImplicitThis must be enabled for this to happen)
• A type reference in JS files (in JS Doc) may omit type parameters, which are defaulted to any
• JS files detect prototype assignment based classes
• JS files show properties from all types in a union in completion lists
• A call to require is assumed to be a module import
• Certain other CommonJS assignments are automatically detected

[RyanCavanaugh]

So yeah we can take a suggestion on something that e.g. turns off all of that behavior, or maybe just the certain aspects that you might find objectionable. That said, all of these were added on purpose based on user feedback and investigation of the ergonomics of writing passing code without the ability to write type assertions, type arguments, or type annotations, so it's worth thinking hard about what the exact trade-off being made is.

"different inputs produce different behavior" is not a prima facie justification - some longer description of what you'd want from this mode would be useful, since simply renaming JS to TS is also a way to get the TS behavior.