search

lit / rfcs

RFCs for changes to Lit
BSD 3-Clause "New" or "Revised" License
15 stars 10 forks source link

Lit 3.0 #16

Closed justinfagnani closed 1 year ago

justinfagnani commented 1 year ago

This is a proposal for a limited set of breaking changes for Lit 3.0.

jogibear9988 commented 1 year ago

should a new major not also be a new npm package name? if someone uses lit2 elements in lit3 and the lit2 are not working with the new major?

justinfagnani commented 1 year ago

@jogibear9988 no we don't need a new package name. This is what npm versions are for.

jogibear9988 commented 1 year ago

sure, but with them you can not mix 2 different lit versions. or can you?

justinfagnani commented 1 year ago

Yes, you can. First, each component depends on a version of Lit and other components don't need to depend on the same version. Lit's an implementation detail. Second we made all internal objects that cross API boundaries have stable APIs and use stable branding so that they work across multiple copies and versions of Lit.

jogibear9988 commented 1 year ago

Yes, you can. First, each component depends on a version of Lit and other components don't need to depend on the same version. Lit's an implementation detail. Second we made all internal objects that cross API boundaries have stable APIs and use stable branding so that they work across multiple copies and versions of Lit.

For me it is still not clear how this would work. If I have a bigger project wich uses v2 and v3 components, the node_modules folder still can contain only one version of lit. And if V3 now has breaking changes, this will maybe break the v2 ones. But this is not only an issue with lit.

Or is "flat" mode of npm/yarn not the mode wich should be used any more (I think I did this since polymer). But if not, how could importmap's be used to resolve different versions of lit (or any other component), if I use no bundler.

augustjk commented 1 year ago

Or is "flat" mode of npm/yarn not the mode wich should be used any more (I think I did this since polymer). But if not, how could importmap's be used to resolve different versions of lit (or any other component), if I use no bundler.

This is a valid concern that does force usage of a single version. To be able to use multiple versions, you'd need to bundle components that use the different versions first, or if not bundling, convert the bare specifiers to include the major version and have separate import map entries for each version, like lit@2 and lit@3 (I haven't seen a tool that does this yet).

That said, Lit 3's breaking change is mainly dropping ie11 support without API changes so upgrading it shouldn't be a problem if you're targeting modern browsers, which you should be if you are considering even the mixed usage of Lit 3.