You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This alleviates type errors when there's a different version of reactive-element that @lit/localize is using versus what the user's component is using.
Because localized is a class decorator, the standard Interface with Omit or Pick was not usable as there were static properties on it that conflict. I tried Pick<typeof ReactiveElement, 'addInitializer'> but the initializer type references ReactiveElement directly which breaks because of renderRoot.
I also removed the dependency on @lit/reactive-element and just import everything from lit.
I do wonder though.. @lit/localize only uses the lit package for types/interfaces. It exports utilities strictly meant to be used with lit projects and nothing is standalone. This is a prime candidate for marking lit as a peer dependency as described in lit/rfcs#31.
I tried it locally by updating the package.json to specify lit as a peer dependency, without the loosened type fix npm pack and installed the tarball in a lit 2 test project that was having type errors before. It no longer errors as it did not create a nested duplicate @lit/reactive-element. But, to be fair, this was also the case with just expanding the dependency version to include lit 2 even as a non-peer regular dependency as npm was able to dedupe it then too.
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.
This alleviates type errors when there's a different version of
reactive-elementthat@lit/localizeis using versus what the user's component is using.Because
localizedis a class decorator, the standardInterfacewithOmitorPickwas not usable as there were static properties on it that conflict. I triedPick<typeof ReactiveElement, 'addInitializer'>but the initializer type referencesReactiveElementdirectly which breaks because ofrenderRoot.I also removed the dependency on
@lit/reactive-elementand just import everything fromlit.I do wonder though..
@lit/localizeonly uses thelitpackage for types/interfaces. It exports utilities strictly meant to be used withlitprojects and nothing is standalone. This is a prime candidate for markinglitas a peer dependency as described in lit/rfcs#31.I tried it locally by updating the package.json to specify lit as a peer dependency, without the loosened type fix
npm packand installed the tarball in a lit 2 test project that was having type errors before. It no longer errors as it did not create a nested duplicate@lit/reactive-element. But, to be fair, this was also the case with just expanding the dependency version to include lit 2 even as a non-peer regular dependency as npm was able to dedupe it then too.