Realized this kinda breaks in the codesandbox demo too:
I tried running the local demo and encountered several problems:
react-windowwas not defined
recoilwas not defined
The other thing that slightly stumped me was all the scary eslint errors from
mp4.js. Since I think its just copy-pasta, I have added it to
.eslintignore for now.
There was also a small warning about
App.js having two
default exports. So I fixed that as well.
Does excalidraw (the repo) expose any primitives or libraries to handle drawing text/image etc? I think tldraw does. I could be wrong.
Fix typo in getting-started.mdx (#1785)
👋 This PR fixes a typo in the Getting Started docs.
Provide a bit more context for trace files. (#1768)
fix(docs): nextjs with-docker link (#1800)
Just a small fix.
Drop unused absolute unix path (#1791)
We don't use, and probably should not use, absolute unix paths. Unix paths are for sharing across machines, and absolute paths are for interacting with the local machine and should always be system paths.
Benchmarks: Install node_modules and reuse test directories (#284)
npm installin test directories to provide turbopack with modules necessary to bundle them.
npm installfor each iteration, improving the times to run benchmarks.
Currently cherry-picks #278 as it's necessary along with #277.
Test Plan: Connected to the running devserver mid-test and confirmed no errors are thrown and the triangle is rendered correctly.
Benchmarks: assert that no runtime errors occur when loading pages (#285)
This adds an assertion that no runtime (browser) errors occurred when loading a benchmark page.
Test Plan: Temporarily removed the npm install for the test app and verified the benchmark failed as the test app requires react, react-dom. Restored the npm install and verified the benchmark runs to completion.
Generate .npmrc just-in-time (#1805)
.npmrc file before publishing, but don't check it into the repo
Co-authored-by: Nathan Hammond email@example.com
fix: use docker cache best practices in examples (#1673)
The whole purpose of the
turbo prune --docker is to use docker caching best practices while the Docker examples do not follow these bests practices.
Plus, I believe that the first stage of the Dockerfile is wrong as it copies the whole project and defeats the entire purpose of the caching because the first layer never gets cached. I believe the most optimized solution is to run the
turbo prune before the
docker build on the machine that runs the
docker build and set the
out directory as the docker build context.
I understand that showing this approach may not be possible in the example, so I suggest we add a comment to the first stage with the above explanation.
Postfix join and try_join (#300)
Instead of dropping back to prefix calling form in
try_join_all(iterator_of_intofutures).await?, we now use postfix form
chore(deps): update dependency @babel/core to v7.18.13 (#1765)
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
dynamic imports for the test app, and fixes (#294)
add the ability to generate an test app with dynamic imports via option.
fixes chunking. It didn't handle async imports in the case where chunk where too large. The PR reuses the same logic for both cases now.
improve vizualization (#225)
chore(packages): typecheck and abstract ts config (#1807)
chore(ci): use remote cache for JS tests (#1808)
Set cmd.Dir to an absolute path when we execute scripts (#1774)
cmd.Dir to an absolute path ensures that it will continue to work in the presence of the
Bonus drop unused
Note that this PR stacks on top of #1773
Remove errant indentation (#1810)
Fix syntax for github action so that it triggers properly
Remove --no-gc flag, always run with garbage collection (#1803)
A parsing bug meant no one was using
--no-gc, so use this opportunity to enable GC. Benchmarks show negligible difference in execution time.
(refactor) add lockfile abstraction (#1789)
This PR introduces a new lockfile abstraction that will allow us to easily add more lockfile support to other package managers. It also
Contextnow stores the lockfile interface instead of a yarn specific lockfile
PackageJsonnow only stores the package names as they appear in the lockfile, these will be mapped to their entries when the pruned lockfile is created
From my understanding of Golang I think having
Lockfile as an interface makes sense since each package manager has a different data layout for their lockfile e.g. pnpm has 6 top level entries and yarn's top level entries are the package entries themselves.
The e2e tests cover yarn prune, but I also tested that prune produces the an identical lockfile before and after these changes on a repo created with
This PR does a few things:
turbopath/absolute_path.goto prevent cycles. These will be removed in a followup commit.
turbopath.AbsolutePath. (excluding the turbopath folder)
The goal here is to make what are sweeping changes to the codebase still feel as incremental as possible. The next increment is
turbopath.AbsoluteSystemPath by combining the files and fixing the expectations of method calls throughout the codebase.
Use parking_lot in tt-memory (#288)
cargo-instruments, I noticed that locking/unlocking the
turbo-tasks-memory was responsible for a significant chunk of the overall execution time.
My first reaction was to try to minimize the lifetime of the
add_to_scope_internal_shallow to avoid
contention. However, it's unclear whether it's lock contention that's causing the slowdown, or if it's just the
locking/unlocking mechanism of
std::sync::RwLock itself. Instead, I switched to
parking_lot::RwLock, and instantly
noticed great improvements.
Benchmark: 30k sierpinski triangles
RUST_BACKTRACE=1 cargo run --bin next-dev --release -- triangles_30k --log-detail Compiling turbo-tasks-memory v0.1.0 (/Users/alex/dev/turbo-tooling/crates/turbo-tasks-memory) Compiling next-dev v0.1.0 (/Users/alex/dev/turbo-tooling/crates/next-dev) Finished release [optimized] target(s) in 9.40s Running `target/release/next-dev triangles_30k --log-detail` server listening on: http://localhost:3000 start watcher /Users/alex/dev/turbo-tooling/triangles_30k/.next/server... start watcher /Users/alex/dev/turbo-tooling/triangles_30k... watching /Users/alex/dev/turbo-tooling/triangles_30k/.next/server... watching /Users/alex/dev/turbo-tooling/triangles_30k... initial compilation 23s (23s task execution, 2476451 tasks) [TaskId 2476470] once took 1977ms [TaskId 2476493] once took 2696ms [TaskId 2476454] once took 3507ms [TaskId 2476514] once took 5026ms [TaskId 2917702] once took 2785ms [TaskId 3083451] once took 1890ms [TaskId 2917653] once took 4440ms [TaskId 2994301] once took 1687ms updated in 48s (1112024 tasks)
Total execution time 71s
RUST_BACKTRACE=1 cargo run --bin next-dev --release -- triangles_30k --log-detail Finished release [optimized] target(s) in 0.57s Running `target/release/next-dev triangles_30k --log-detail` server listening on: http://localhost:3000 start watcher /Users/alex/dev/turbo-tooling/triangles_30k... start watcher /Users/alex/dev/turbo-tooling/triangles_30k/.next/server... watching /Users/alex/dev/turbo-tooling/triangles_30k... watching /Users/alex/dev/turbo-tooling/triangles_30k/.next/server... initial compilation 5670ms (5602ms task execution, 2476451 tasks) updated in 12s (1112024 tasks) updated in 3.173ms (26 tasks) updated in 2.579ms (48 tasks) updated in 0.017ms (0 tasks)
Total execution time 18s
Task::add_to_scope_internal_shallow is still a very hot path, and three things stand out:
Replacing it with
parking_lot::Mutex yields even greater improvements:
RUST_BACKTRACE=1 cargo run --bin next-dev --release -- triangles_30k --log-detail Compiling turbo-tasks-memory v0.1.0 (/Users/alex/dev/turbo-tooling/crates/turbo-tasks-memory) Compiling next-dev v0.1.0 (/Users/alex/dev/turbo-tooling/crates/next-dev) Finished release [optimized] target(s) in 7.12s Running `target/release/next-dev triangles_30k --log-detail` server listening on: http://localhost:3000 start watcher /Users/alex/dev/turbo-tooling/triangles_30k... start watcher /Users/alex/dev/turbo-tooling/triangles_30k/.next/server... watching /Users/alex/dev/turbo-tooling/triangles_30k... watching /Users/alex/dev/turbo-tooling/triangles_30k/.next/server... initial compilation 5621ms (5513ms task execution, 2476451 tasks) updated in 8128ms (1112023 tasks)
Total execution time 14s (5x speedup!)
Looking at the traces, it looks like there's more low-hanging fruits for further optimizing turbo-tasks and turbopack.
This was tested on macOS 12.5.1, Apple M1 Max, 32GB.