-
-
Notifications
You must be signed in to change notification settings - Fork 123
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
Fix .clear()
behavior
#136
Conversation
Fixes #135
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome to see!
source/index.ts
Outdated
*/ | ||
clear(): void { | ||
const keys = Object.keys(this.store); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the current value of the store has a key deleted that is in the defaults or schema, I believe it wouldn't be included in this and you'd end up with an incomplete default.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch: 8b1ee0b
|
||
for (const key of keys) { | ||
this.reset(key); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it'd make sense to emit the change event here, what do you think?
this.events.emit('change');
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That is already done, since we set this.store
:
Line 344 in 43c644f
this.events.emit('change'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@sindresorhus this is actually causing a regressive bug in my program. While we set this.store, we do it before reseting the parameters, and we set it to a blank object—which disobeys the type contract. Subsequently it's emitting an onDidAnyChange event where the current value is undefined (which disobeys the type guarantees for the store, given defaults)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this doesn't cause a static typing violation because of the use Partial in several places where I don't believe it makes sense. Ideally it'd be possible to create a Conf with strict type guarantee. The type of details should statically guaranteed to be the base type.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't have the time to look into this right now, so it would be good if you could open an issue instead. Even better if you could also submit some failing tests.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I created an issue. The type safety bug here is pretty important. The clear() bug is as well, given that is breaks the contract with the client regarding types.
excited to see this land! only remaining concern is that this is probably a breaking change for people who rely on public clear(restoreDefaults?: boolean): void so that people like me can just pass |
It's really just a bug fix, but I will do a major release just to be careful. |
Fixes #135