Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

[P2] Tests: lazy class storage test expects erased declare fields at runtime

Open Beginner friendly
  • Is something wrong?
#2,829 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
1/5
Estimated time
1-3 hours
Newbie friendliness
84/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
csharp, typescript
Domain
compilers, testing

Research direction

Find LazyClassFieldStorageTests.GenericDeclareAndComputedInitializers_MaterializeAndVerify and review its expected output alongside the provided TypeScript source. Run the test to confirm the mismatch; done means updating only the expected output to match Node's result while preserving the source and complete IL-verification assertion.

Written by the indexing model from the issue text.

Description

bug priority: P2

The existing compiler test LazyClassFieldStorageTests.GenericDeclareAndComputedInitializers_MaterializeAndVerify expects a declare field to exist on the emitted instance and contain null.

Its unchanged source is:

const key: string = "computed";
class Box<T> {
    value: T;
    declare absent: any;
    [key]: number = 2;
    constructor(value: T) { this.value = value; }
}
const box: any = new Box<number>(3);
console.log(box.value, box.absent, box.computed,
    Object.hasOwn(box, "absent"), Object.hasOwn(box, "computed"));

Strict TypeScript accepts this source. Node prints:

3 undefined 2 false true

The test still expects:

3 null 2 true true

A declare field is erased, so the Node result is the intended runtime behavior. Both the tested compiler parent and the candidate for #2737 produce the correct result after complete IL verification with only System assembly references. The assertion therefore fails on both; this is a stale test oracle, not a runtime regression from #2737.

Update the expected output while preserving the complete source and the existing IL-verification assertion. Found while expanding #2737 validation. The original test was added with the lazy-storage work associated with #1459.

Dominant language
C#
Stars
156
Forks
4
Avg merge
5h 24m
Merged PRs (30d)
68

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from nickna/SharpTS

All issues in nickna/SharpTS

Similar issues

More C# issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.