Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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 ensure hashed directory for extension #7188
Fix ensure hashed directory for extension #7188
Changes from 2 commits
65afe3c
b2a1ee6
9405899
4b6bfc1
169bb1b
8d9d710
b729962
795084d
845c727
080ae95
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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'm thinking if case of NPM-packages with a namespaced name (eg.
"name": "@some-namespace/some-package-name"
) will require their own tests and maybe implementations. WDYT?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.
Note: Another way to test
ensureDir
and its effects would be to test it using those file system fakes. Generally it leads to bit more credible, but also sometimes easier to write 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.
Hmm. I wonder if
registeredExtensions
could be promoted to be a dependency instead of function parameter for a bit less complexity. There's only one set of those, right?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.
Is there only one? I'm not sure. That is a part of
Store
, does it have some kind main / renderer thing going on with syncing stuff. Can we moveregisteredExtensions
from the Store to a dependency?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.
There indeed is only one, because
fileSystemProvisionerStoreInjectable
is asingleton
(that being the default lifecycle of aninjectable
).This means we could extract eg.
registeredExtensionsInjectable
, and make it a dependency for bothfileSystemProvisionerStoreInjectable
andensureHashedDirectoryForExtensionInjectable
.Being diligent about separating dependencies and eg. function arguments will lead to a cleaner kitchen, as it creates more easily reusable functions, and hides irrelevant details out of sight.
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.
To test eg.
expect(actual).toBe("some-random-directory");
would be more credible.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, fixed