A simple, elegant, fast & open source file explorer for Android
A JQuery plugin for a commandline emulator with custom interpreters and formatter
Realized this kinda breaks in the codesandbox demo too:
I tried running the local demo and encountered several problems:
react-window
was not definedrecoil
was not definedThe 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)
This:
npm install
in test directories to provide turbopack with modules necessary to bundle them.npm install
for 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)
Generate the .npmrc
file before publishing, but don't check it into the repo
Co-authored-by: Nathan Hammond 20542+nathanhammond@users.noreply.github.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 iterator_of_intofutures.try_join().await?
.
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)
Setting cmd.Dir
to an absolute path ensures that it will continue to work in the presence of the --cwd
flag.
Bonus drop unused turboCache
from execContext
.
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)
This PR:
--no-gc
flagA 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
Notable changes:
Context
now stores the lockfile interface instead of a yarn specific lockfilePackageJson
now only stores the package names as they appear in the lockfile, these will be mapped to their entries when the pruned lockfile is createdFrom 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.
Testing:
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 npx create-turbo
.
Move fs.AbsolutePath
to turbopath.AbsolutePath
(#1779)
This PR does a few things:
fs.AbsolutePath
to turbopath.AbsolutePath
.fs
into turbopath/absolute_path.go
to prevent cycles. These will be removed in a followup commit.\b(fs\.)?AbsolutePath\b
=> 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.AbsolutePath
to turbopath.AbsoluteSystemPath
by combining the files and fixing the expectations of method calls throughout the codebase.
Use parking_lot in tt-memory (#288)
While profiling next-dev
using cargo-instruments
, I noticed that locking/unlocking the RwLock<TaskState>
in
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 WriteGuard
in 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
Before:
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
After:
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:
Vec
for children;HashMap::entry
;Mutex<TaskScopeState>
in TaskScope
:
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.
Traces: traces.zip