Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dependants do not rebuild when changing something in a dependency #169

Closed
Jarrku opened this issue Dec 10, 2021 · 0 comments · Fixed by #173
Closed

Dependants do not rebuild when changing something in a dependency #169

Jarrku opened this issue Dec 10, 2021 · 0 comments · Fixed by #173

Comments

@Jarrku
Copy link

Jarrku commented Dec 10, 2021

What version of Turborepo are you using?

1.0.4

Describe the Bug

Dependant projects hit a cache if only a dependency has changed. Changing something to packages/ui should result in a rebuild of the apps.

Expected Behavior

if I change something in packages/ui, I'd expect that the dependants (apps/docs | apps/web) would not hit a cache and rebuild.

To Reproduce

  • Run npx create-turbo
  • yarn build to build the cache
  • Change something in packages/ui/Button.tsx
  • Rerun yarn build -> Everything is outputted as already built.
sokra pushed a commit that referenced this issue Oct 25, 2022
Cherry-picking this from my work on the next-dev test runner.

This moves browser opening from the turbopack-dev-server crate into the next-dev crate, which has the cli entrypoint that runs the dev server. It looks like the dev server package is meant to be used as a library (it's only a library crate), and having this external side effect feels unexpected and makes it difficult to use this crate in situations like a test runner for next-dev, where we should test with a headless web browser.

Alternatively, opening the browser could be an option passed when creating the dev server, but this feels a bit cleaner to me.

Test Plan: `cargo run -p next-dev` and verify the browser still opens and successfully connects to the dev server.
sokra added a commit that referenced this issue Oct 25, 2022
jridgewell pushed a commit to vercel/next.js that referenced this issue Mar 10, 2023
Cherry-picking this from my work on the next-dev test runner.

This moves browser opening from the turbopack-dev-server crate into the next-dev crate, which has the cli entrypoint that runs the dev server. It looks like the dev server package is meant to be used as a library (it's only a library crate), and having this external side effect feels unexpected and makes it difficult to use this crate in situations like a test runner for next-dev, where we should test with a headless web browser.

Alternatively, opening the browser could be an option passed when creating the dev server, but this feels a bit cleaner to me.

Test Plan: `cargo run -p next-dev` and verify the browser still opens and successfully connects to the dev server.
jridgewell pushed a commit to vercel/next.js that referenced this issue Mar 10, 2023
sokra pushed a commit to vercel/next.js that referenced this issue Mar 13, 2023
Cherry-picking this from my work on the next-dev test runner.

This moves browser opening from the turbopack-dev-server crate into the next-dev crate, which has the cli entrypoint that runs the dev server. It looks like the dev server package is meant to be used as a library (it's only a library crate), and having this external side effect feels unexpected and makes it difficult to use this crate in situations like a test runner for next-dev, where we should test with a headless web browser.

Alternatively, opening the browser could be an option passed when creating the dev server, but this feels a bit cleaner to me.

Test Plan: `cargo run -p next-dev` and verify the browser still opens and successfully connects to the dev server.
sokra added a commit to vercel/next.js that referenced this issue Mar 13, 2023
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant