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
Conversation
Earlier open lens versions stored extension_data directory based on path of extension's package.json. This causes problems because extensions have moved to new location. This ensures backward compatibility that extension will get the same directory than before the change. Signed-off-by: Juho Heikka <juho.heikka@gmail.com>
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 understand why this is needed.
...ion-loader/file-system-provisioner-store/ensure-hashed-directory-for-extension.injectable.ts
Outdated
Show resolved
Hide resolved
...ion-loader/file-system-provisioner-store/ensure-hashed-directory-for-extension.injectable.ts
Outdated
Show resolved
Hide resolved
Signed-off-by: Juho Heikka <juho.heikka@gmail.com>
...extension-loader/file-system-provisioner-store/ensure-hashed-directory-for-extension.test.ts
Outdated
Show resolved
Hide resolved
|
||
export type GetPathToLegacyPackageJson = (extensionName: string) => string; | ||
|
||
const getPathToLegacyPackageJson = getInjectable({ |
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 could be unit tested as part of ensure-hashed-directory-for-extension.test.ts
, instead of coupling tests too tightly with implementation details.
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.
sure we can just get rid off the specific tests for this dependency
|
||
const actual = await ensureHashedDirectoryForExtension( | ||
"some-extension-name", | ||
registeredExtensions, |
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 move registeredExtensions
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 a singleton
(that being the default lifecycle of an injectable
).
This means we could extract eg. registeredExtensionsInjectable
, and make it a dependency for both fileSystemProvisionerStoreInjectable
and ensureHashedDirectoryForExtensionInjectable
.
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.
|
||
ensureDirMock = jest.fn(); | ||
|
||
di.override(ensureDirInjectable, () => ensureDirMock); |
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.
expect(actual).toBe("some-directory"); | ||
}); | ||
|
||
it("given extension directory was saved based on extension's package.json path, ensure dir is called with right parameter", async () => { |
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.
Instead of "right parameter", one could document what makes the parameter 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.
good call. done
...sions/extension-loader/file-system-provisioner-store/get-path-to-legacy-package-json.test.ts
Outdated
Show resolved
Hide resolved
...extension-loader/file-system-provisioner-store/get-path-to-legacy-package-json.injectable.ts
Outdated
Show resolved
Hide resolved
registeredExtensions, | ||
); | ||
|
||
expect(actual).not.toBe("some-directory"); |
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
import directoryForExtensionDataInjectable from "./directory-for-extension-data.injectable"; | ||
import directoryForUserDataInjectable from "../../../common/app-paths/directory-for-user-data/directory-for-user-data.injectable"; | ||
|
||
describe("ensure-hashed-directory-for-extension", () => { |
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?
...ion-loader/file-system-provisioner-store/ensure-hashed-directory-for-extension.injectable.ts
Outdated
Show resolved
Hide resolved
...sions/extension-loader/file-system-provisioner-store/get-path-to-legacy-package-json.test.ts
Outdated
Show resolved
Hide resolved
Signed-off-by: Juho Heikka <juho.heikka@gmail.com>
Signed-off-by: Juho Heikka <juho.heikka@gmail.com>
Signed-off-by: Juho Heikka <juho.heikka@gmail.com>
1c9e881
to
8d9d710
Compare
Signed-off-by: Juho Heikka <juho.heikka@gmail.com>
expect(actual).toBe("some-directory"); | ||
}); | ||
|
||
it("ensure dir is called with some directory", async () => { |
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.
"ensure dir" is a technical phenomenon, and in general, unit tests benefit more from describing motivations of the real world. That would mean eg.: it("ensures that the said extension directory exists", ...)
.
Signed-off-by: Juho Heikka <juho.heikka@gmail.com>
* Fix ensure hashed directory for extension Earlier open lens versions stored extension_data directory based on path of extension's package.json. This causes problems because extensions have moved to new location. This ensures backward compatibility that extension will get the same directory than before the change. Signed-off-by: Juho Heikka <juho.heikka@gmail.com> * Reconstruct the key for old hashed directories Signed-off-by: Juho Heikka <juho.heikka@gmail.com> * Remove unnecessary return Signed-off-by: Juho Heikka <juho.heikka@gmail.com> * Use sync version of random bytes Signed-off-by: Juho Heikka <juho.heikka@gmail.com> * Add migration to new type of key Signed-off-by: Juho Heikka <juho.heikka@gmail.com> * Fix global override for random bytes to not return a promise Signed-off-by: Juho Heikka <juho.heikka@gmail.com> * Make registeredExtensions a dependency Signed-off-by: Juho Heikka <juho.heikka@gmail.com> --------- Signed-off-by: Juho Heikka <juho.heikka@gmail.com> (cherry picked from commit d8acff6)
* Fix ensure hashed directory for extension Earlier open lens versions stored extension_data directory based on path of extension's package.json. This causes problems because extensions have moved to new location. This ensures backward compatibility that extension will get the same directory than before the change. Signed-off-by: Juho Heikka <juho.heikka@gmail.com> * Reconstruct the key for old hashed directories Signed-off-by: Juho Heikka <juho.heikka@gmail.com> * Remove unnecessary return Signed-off-by: Juho Heikka <juho.heikka@gmail.com> * Use sync version of random bytes Signed-off-by: Juho Heikka <juho.heikka@gmail.com> * Add migration to new type of key Signed-off-by: Juho Heikka <juho.heikka@gmail.com> * Fix global override for random bytes to not return a promise Signed-off-by: Juho Heikka <juho.heikka@gmail.com> * Make registeredExtensions a dependency Signed-off-by: Juho Heikka <juho.heikka@gmail.com> --------- Signed-off-by: Juho Heikka <juho.heikka@gmail.com>
Earlier open lens versions stored
extension_data
directory based on path of extension's package.json. This causes problems because extensions have moved to new location. This ensures backward compatibility that extension will get the same directory than before the change and migrates the key to a new implementation that does not depend on the installed directory.Fixes #7052