ci(examples): test examples in CI

[lachlancollins]

• Removed --exclude=examples/** from test:pr and test:ci
• Fixed up some examples (nextjs, svelte, solid)
• Removed NX_CLOUD_AUTH_TOKEN (alias of NX_CLOUD_ACCESS_TOKEN)

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

1 Ignored Deployment

Name	Status	Preview	Comments	Updated (UTC)
query	⬜️ Ignored (Inspect)	Visit Preview		Feb 3, 2024 4:51am

[nx-cloud]

☁️ Nx Cloud Report

CI is running/has finished running commands for commit 383b9ff. As they complete they will appear below. Click to see the status, the terminal output, and the build insights.

📂 See all runs for this CI Pipeline Execution

---

✅ Successfully ran 1 target

• nx affected --targets=test:eslint,test:lib,test:types,test:build,build

---

Sent with 💌 from NxCloud.

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit 383b9ff:

Sandbox	Source
@tanstack/query-example-angular-basic	Configuration
@tanstack/query-example-react-basic-typescript	Configuration
@tanstack/query-example-solid-basic-typescript	Configuration
@tanstack/query-example-svelte-basic	Configuration
@tanstack/query-example-vue-basic	Configuration

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (237e52c) 41.78% compared to head (383b9ff) 41.78%.

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #6813   +/-   ##
=======================================
  Coverage   41.78%   41.78%           
=======================================
  Files         178      178           
  Lines        7017     7017           
  Branches     1421     1421           
=======================================
  Hits         2932     2932           
  Misses       3722     3722           
  Partials      363      363           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[TkDodo]

The difference between examples and integrations was that examples depend on ^5.x so that they can run in codesandbox and stackblitz after we've released a new version, while the integrations depend on workspace:* so that they build with code on a PR before we have released it to find potential errors upfront. They were different use-cases and I think the split was good. I don't think it makes sense to spend CI time to "test" the same vite setup multiple times...

[lachlancollins]

The difference between examples and integrations was that examples depend on ^5.x so that they can run in codesandbox and stackblitz after we've released a new version, while the integrations depend on workspace:* so that they build with code on a PR before we have released it to find potential errors upfront. They were different use-cases and I think the split was good. I don't think it makes sense to spend CI time to "test" the same vite setup multiple times...

I agree that it's annoying to have longer CI times, but I believe there is benefit to ensuring examples can build and pass type checks - it adds confidence that the examples work for users out-of-the-box. This PR found and fixed several places where our examples didn't work. Luckily with Nx caching, the added time isn't too bad when the cache hits.

I did forget that I had workspace:* in these apps, so this would need to change.

[TkDodo]

I'm fine with type checking the examples but building integrations separately seems better. The integrations aren't examples. You can't run them, they don't do anything meaningful. If all examples in the example directory show up automatically on the docs page, this would be highly confusing.

It's also easier to get an overview of which frameworks in which version have coverage if those are in a separate directory

[lachlancollins]

I'm fine with type checking the examples but building integrations separately seems better. The integrations aren't examples. You can't run them, they don't do anything meaningful. If all examples in the example directory show up automatically on the docs page, this would be highly confusing.

It's also easier to get an overview of which frameworks in which version have coverage if those are in a separate directory

That's a good point about being able to easily see the full list of covered frameworks. Since the vite and next builds were covered by examples directory, I thought it might be a small CI time gain to remove them.

R.e. the website: examples need to be added to the docs config to show up in the sidebar, so the integrations moved to examples don't show up.

[TkDodo]

R.e. the website: examples need to be added to the docs config to show up in the sidebar, so the integrations moved to examples don't show up.

I'm aware, this was just a hypothetical scenario where all things in the examples dir show up automatically :)

the main points for separation are:

• knowing which frameworks are covered
• integrations depend on workspace:*, examples depend on ^5.x
  • examples are runnable outside of the monorepo because of that, integrations are not
• type-checking examples is fine, building them is rather pointless

[lachlancollins]

R.e. the website: examples need to be added to the docs config to show up in the sidebar, so the integrations moved to examples don't show up.

I'm aware, this was just a hypothetical scenario where all things in the examples dir show up automatically :)

the main points for separation are:

• knowing which frameworks are covered

• integrations depend on workspace:*, examples depend on ^5.x

  • examples are runnable outside of the monorepo because of that, integrations are not

• type-checking examples is fine, building them is rather pointless

I've re-separated integrations in #6821 :) thanks for the feedback!