[BUG] Network type interpreted as ANY
Nobody has claimed this yet.
Assessment
- Difficulty
- 1/5
- Estimated time
- Under an hour
- Newbie friendliness
- 50/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Stale
- Tech stack
- typescript
- Domain
- networking
Research direction
Start in src/types/network.d.ts by inspecting the EmptyNetwork and ValidNetwork declarations and how TypeScript infers Network. Update the type relationship so EmptyNetwork no longer causes an any type, then verify that Network has the intended type and the project's TypeScript checks pass.
Written by the indexing model from the issue text.
Description
Describe the bug
EmptyNetwork is defined using ValidNetwork<string, never>, which suggests that ValidNetwork was intended to be a generic type. However, ValidNetwork is defined as a concrete type with specific properties and does not accept generic parameters. This is why TypeScript interprets EmptyNetwork as any.
To Reproduce
Steps to reproduce the behavior:
- Go to: src/types/network.d.ts
- Check type of EmptyNetwork
Expected behavior
If the goal is to create a type EmptyNetwork that represents a "network" with potentially missing or empty fields based on ValidNetwork, generics should not be used in this case.
Instead, you can use utility types like Partial for making all properties optional or use other TypeScript features to modify the existing ValidNetwork type.
Screenshots
Additional context
In the current implementation the type of Network is quite useless, because it implies being "any" because of this incosistency with EmptyNetwork.
Possible solution would look something like this:
type EmptyNetwork = Partial<ValidNetwork>;
- Dominant language
- TypeScript
- Stars
- 63
- Forks
- 79
- Avg merge
- 16h 15m
- Merged PRs (30d)
- 10
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from scroll-tech/frontends
-
Dependency Dashboard Open
Difficulty 4/5 3-5 days Newbie friendliness 20/100
scroll-tech/frontends#1386 ·
-
Difficulty 3/5 1-2 days Newbie friendliness 38/100
scroll-tech/frontends#1306 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 38/100
scroll-tech/frontends#1301 · 1 comment ·
-
徽章铸造问题 Open
Difficulty 4/5 3-5 days Newbie friendliness 35/100
scroll-tech/frontends#1292 ·
-
资源包版本 Open
Difficulty 5/5 Over a week Newbie friendliness 20/100
scroll-tech/frontends#1291 ·
All issues in scroll-tech/frontends
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
Eynzof/Hermes-CN-Desktop#610 ·
-
bug clawsweeper:linked-pr-open clawsweeper:needs-live-repro clawsweeper:no-new-fix-pr impact:message-loss issue-rating: 🐚 platinum hermit P2 regression
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
calcite-components needs triage refactor
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Esri/calcite-design-system#15203 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 90/100
danielmiessler/LifeOS#2218 ·