diff --git a/docs/guides/component-testing/third-party-definitions.mdx b/docs/guides/component-testing/third-party-definitions.mdx index bf653c0fa4..b058a79767 100644 --- a/docs/guides/component-testing/third-party-definitions.mdx +++ b/docs/guides/component-testing/third-party-definitions.mdx @@ -63,7 +63,7 @@ When configuring a project to use Component Testing, Cypress will load any dependencies following this naming convention from the project's `node_modules` and present them as framework options. -A simple example of a Framework Defintion for the +A simple example of a Framework Definition for the [Solid.js](https://www.solidjs.com/) library is shown below. We generally recommend naming this `definition.cjs`. In our [official template](https://github.com/cypress-io/cypress-ct-definition-template), @@ -167,7 +167,8 @@ indicating it's a third party definition. We defined the `dependencies`, which are also correctly handled - we haven't @@ -175,9 +176,29 @@ installed them all, so Cypress is prompting us to do so: +From Cypress version 12.10.0, if there is a problem loading or +parsing a framework definition, Cypress will display a warning: + + + +To see more detailed error information, use the +`scaffold-config:ct-detect-third-party` namespace for +[logging](/guides/references/troubleshooting#Print-DEBUG-logs), like this: + +```bash +DEBUG=cypress:scaffold-config:ct-detect-third-party npx cypress open +``` + ## Mount Adapter The second part of defining a Framework Definition is the Mount Adapter. This is diff --git a/static/img/guides/component-testing/framework-definition-errors.png b/static/img/guides/component-testing/framework-definition-errors.png new file mode 100644 index 0000000000..93fb6d1db8 Binary files /dev/null and b/static/img/guides/component-testing/framework-definition-errors.png differ