Wolfgang Ziegler

>What do you think? Is there any way around this? Yeah, standardization & documentation. If we could standardize on using asset-packagist (or an alternative on d.o. infrastructure) this would be...

we also ran into this when prototyping a nuxt3 of https://github.com/drunomics/nuxtjs-drupal-ce - we are using the vue run-time compiler to render markup with custom-elements provided by the CMS.

I ran into this as well. A separate ENV-URL would be best, but documenting it would be a good quickfix-

I agree, that would be nice to support! In the end the change in server-routes to support it would be dead simple. Maybe we could just make our event handleres...

This suggestion seems awesome! One thought: It might be useful to define a default hydration behaviour for a component, like making it a server component. e.g. hydrate:when-visible would be a...

instead of this component, we should just improve drupal-markup component and optionally allow specify a "wrapper" (wrapper tag). So when a wrapper-tag is specified, we would not remove the display-styles...

it seems like existing tests use some sort of E2E testing with a mocked backend when they should do unit testing. e.g. tests for addRequestFormat() would be a typical unit...

#280 has added a first working unit test + necessary setup, so we can start refactoring others based upon this example. everything we can test just by rendering components and...

https://github.com/drunomics/nuxtjs-drupal-ce/commit/4c5c319a41b5c89c1e7ff55c82c40932f464e59f#diff-2ee894bf23aa44ff4ce12a3da8af19ab20180474ebf2176dbe5f2eea3f96dc92 added the config such that we can unit-test with nuxt environment that has the module installed, with that we can finally unit test components.

added more unit tests in #285 - given the existing pattern this is now easy for further components. I think we can now start overhauling existing tests to apply to...