-
Notifications
You must be signed in to change notification settings - Fork 9
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
Remove CommonJS dependencies #171
Labels
Comments
See https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypto/digest for generating a hash with native Web API. |
Marcarrian
added a commit
that referenced
this issue
Nov 8, 2022
closes #162, closes #171 BREAKING CHANGE: Using unique identifier for capability and intention ID introduced a breaking change. Previously, the IDs used for capabilities and intentions were stable but not unique, which caused problems when deregistering capabilities and intentions. If your application requires stable capability identifiers, you can register a capability interceptor, as follows: ```ts import {Capability, CapabilityInterceptor} from '@scion/microfrontend-platform'; import {Crypto} from '@scion/toolkit/crypto'; import {Beans} from '@scion/toolkit/bean-manager'; Beans.register(CapabilityInterceptor, { useValue: new class implements CapabilityInterceptor { public async intercept(capability: Capability): Promise<Capability> { const stableId = await Crypto.digest(JSON.stringify({ type: capability.type, qualifier: capability.qualifier, application: capability.metadata!.appSymbolicName, })); return { ...capability, metadata: {...capability.metadata!, id: stableId}, }; } }, multi: true }) ```
Marcarrian
added a commit
that referenced
this issue
Nov 8, 2022
closes #162, closes #171 BREAKING CHANGE: Using unique identifier for capability and intention ID introduced a breaking change. Previously, the IDs used for capabilities and intentions were stable but not unique, which caused problems when deregistering capabilities and intentions. If your application requires stable capability identifiers, you can register a capability interceptor, as follows: ```ts import {Capability, CapabilityInterceptor} from '@scion/microfrontend-platform'; import {Crypto} from '@scion/toolkit/crypto'; import {Beans} from '@scion/toolkit/bean-manager'; Beans.register(CapabilityInterceptor, { useValue: new class implements CapabilityInterceptor { public async intercept(capability: Capability): Promise<Capability> { const stableId = await Crypto.digest(JSON.stringify({ type: capability.type, qualifier: capability.qualifier, application: capability.metadata!.appSymbolicName, })); return { ...capability, metadata: {...capability.metadata!, id: stableId}, }; } }, multi: true }) ```
Marcarrian
added a commit
that referenced
this issue
Nov 8, 2022
closes #162, closes #171 BREAKING CHANGE: Using unique identifier for capability and intention ID introduced a breaking change. Previously, the IDs used for capabilities and intentions were stable but not unique, which caused problems when deregistering capabilities and intentions. If your application requires stable capability identifiers, you can register a capability interceptor, as follows: ```ts import {Capability, CapabilityInterceptor} from '@scion/microfrontend-platform'; import {Crypto} from '@scion/toolkit/crypto'; import {Beans} from '@scion/toolkit/bean-manager'; Beans.register(CapabilityInterceptor, { useValue: new class implements CapabilityInterceptor { public async intercept(capability: Capability): Promise<Capability> { const stableId = await Crypto.digest(JSON.stringify({ type: capability.type, qualifier: capability.qualifier, application: capability.metadata!.appSymbolicName, })); return { ...capability, metadata: {...capability.metadata!, id: stableId}, }; } }, multi: true }) ``` Note that the communication protocol between host and client has NOT changed.
17 tasks
Marcarrian
added a commit
that referenced
this issue
Nov 8, 2022
closes #162, closes #171 BREAKING CHANGE: Using unique identifier for capability and intention ID introduced a breaking change. Previously, the IDs used for capabilities and intentions were stable but not unique, which caused problems when deregistering capabilities and intentions. If your application requires stable capability identifiers, you can register a capability interceptor, as follows: ```ts import {Capability, CapabilityInterceptor} from '@scion/microfrontend-platform'; import {Crypto} from '@scion/toolkit/crypto'; import {Beans} from '@scion/toolkit/bean-manager'; Beans.register(CapabilityInterceptor, { useValue: new class implements CapabilityInterceptor { public async intercept(capability: Capability): Promise<Capability> { const stableId = await Crypto.digest(JSON.stringify({ type: capability.type, qualifier: capability.qualifier, application: capability.metadata!.appSymbolicName, })); return { ...capability, metadata: {...capability.metadata!, id: stableId}, }; } }, multi: true }) ``` Note that the communication protocol between host and client has NOT changed. You can independently upgrade host and clients to the new version.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Is your feature request related to a problem? Please describe.
The SCION Microfrontend platform depends on
js-sha256
to compute the identity for capabilities and intentions. Since this dependency is not yet published as an ESM module, it can cause optimization bailouts.Describe the solution you'd like
Look for an alternative way to calculate a hash for an object. Also consider generating a UUID instead of computing a hash, since the platform does not require stable identities, only the
@scion/workbench
. See issue #162 for more information.Related to issue #162.
The text was updated successfully, but these errors were encountered: