Skip to content

More stale errors in tsbuildinfo file (with incremental:true) #49527

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
samreid opened this issue Jun 13, 2022 · 0 comments · Fixed by #49543
Closed

More stale errors in tsbuildinfo file (with incremental:true) #49527

samreid opened this issue Jun 13, 2022 · 0 comments · Fixed by #49543
Assignees
Labels
Fix Available A PR has been opened for this issue

Comments

@samreid
Copy link

samreid commented Jun 13, 2022

Bug Report

@zepumph and I observed incorrect behavior from tsc when incremental was set to true. A similar behavior was also discussed in #42769. It seems like the tsbuildinfo is stale.

🔎 Search Terms

incremental, stale, tsbuildinfo

🕗 Version & Regression Information

  • This is the behavior in 4.6.3 and 4.7.3

💻 Code

// ###################### js/MessageablePerson.ts ##############
const Messageable = () => {
  return class MessageableClass {
    public message = 'hello';
  }
};

const wrapper = () => Messageable();
type MessageablePerson = InstanceType<ReturnType<typeof wrapper>>;
export default MessageablePerson;

// ###################### js/main.ts ##############
import MessageablePerson from './MessageablePerson.js';

function logMessage( person: MessageablePerson ) {
  console.log( person.message );
}

// ###################### ./tsconfig.json ##############
{
  "compilerOptions": {
    "incremental": true,
    "target": "ES2020",
    "module": "ES2020",
    "declaration": false,
    "outDir": "./outDir",
    "composite": false,
    "noEmit": true
  },
  "include": [
    "js/**/*"
  ]
}

🙁 Actual behavior

  1. Set up the 3 files described above, note the relative paths
  2. Run tsc. Observe that type checking passes, as expected
  3. Change public message = 'hello'; to protected message = 'hello'; and run tsc. Observe that type checking fails, as expected. The error message is js/main.ts:5:23 - error TS2445: Property 'message' is protected and only accessible within class 'MessageableClass' and its subclasses.
  4. Change protected message = 'hello'; back to public message = 'hello'; and run tsc. Observe that type checking fails when it should have succeeded. Same error message as in prior step.
  5. Change "incremental": true, to "incremental": false, in the tsconfig file and run tsc. Observe that type checking succeeds as expected.

🙂 Expected behavior

  • In Step 4, we would have expected no type errors, since message is public. However, tsc reports a type error.
  • In Step 5, we would expect no change in behavior whether incremental is set to true or false.
  • Note that we experimented with combining main into the MessageablePerson file and could not exhibit the bug in that way
  • Note also that the bug appears in both ways: (a) reporting an error when there isn't one and (b) reporting that there is no error when there really is an error.
sheetalkamat added a commit that referenced this issue Jun 14, 2022
…can be more accurate for detecting changes to file that could affect other files

Fixes #49527
@sheetalkamat sheetalkamat self-assigned this Jun 14, 2022
@RyanCavanaugh RyanCavanaugh added the Needs Investigation This issue needs a team member to investigate its status. label Jun 15, 2022
@sheetalkamat sheetalkamat added Fix Available A PR has been opened for this issue and removed Needs Investigation This issue needs a team member to investigate its status. labels Jun 23, 2022
sheetalkamat added a commit that referenced this issue Jun 27, 2022
…tal mode use d.ts emit text + diagnostics as signature of the file (#49543)

* Add test when declaration emit has errors and d.ts emit doesnt change which results in incorrect incremental behaviour

* Refactor

* Use declaration diagnostics in the d.ts signature for the file so it can be more accurate for detecting changes to file that could affect other files
Fixes #49527

* Renames and clarifications

* Simplify serialize declaration diagnostics for signature purpose
Do not serialize file name if error is in same file we are emitting. this should avoid having to do file path computation in most cases.
Locations are start and length instead of line and character.
Do not use any indents

* Fix baselines
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Fix Available A PR has been opened for this issue
Projects
None yet
3 participants