Small nit, but if we want to listen on 0.0.0.0, then we should set that
to the default. The difference is that other computers can connect when
we listen on 0.0.0.0, while only this computer can connect if we listen
on 127.0.0.1.
Note that this doesn't completely close out
[vercel/turbo#54](https://github.com/vercel/web-tooling-internal/issues/54) as the
[tailwindcss config is
optional](https://tailwindcss.com/docs/configuration). I'm digging
deeper at additional ways to detect tailwind, but putting this up since
it's a strict improvement.
```
olszewski@chriss-mbp next-dev % cargo run -p next-dev -- /tmp/with-tailwindcss-app
Compiling next-dev v0.1.0 (/Users/olszewski/code/vercel/the-three-body/crates/next-dev)
Finished dev [unoptimized + debuginfo] target(s) in 11.61s
Running `/Users/olszewski/code/vercel/the-three-body/target/debug/next-dev /tmp/with-tailwindcss-app`
server listening on: http://localhost:3000
error [unimplemented]
/private/tmp/with-tailwindcss-app/next.config.js
Feature not yet supported
Handling the file `next.config.js` is currently unimplemented
/private/tmp/with-tailwindcss-app/postcss.config.js
Feature not yet supported
Handling the file `postcss.config.js` is currently unimplemented
/private/tmp/with-tailwindcss-app/tailwind.config.js
Feature not yet supported
Handling the file `tailwind.config.js` is currently unimplemented
[200] / (3045ms)
initial compilation 3468ms (3044ms task execution, 48380 tasks)
updated in 874ms (8990 tasks)
```
Ported from https://github.com/vercel/turbo-tooling/pull/452.
To do:
* [x] Read and use node version from PATH
Test Plan:
Temporarily lowered the default version and verified core-js was
resolved when /page is visited.
Co-authored-by: Justin Ridgewell <justin@ridgewell.name>
Fixes a few issues:
1. Removes `Hasher` impl for `Xxh3Hash64Hasher`
- Importing the `Hash` trait allows you to call `vc.hash(&mut
xxh3_hasher)`, which defeats our goal of deterministic hashing
2. Fixes hashing of 2 contiguous strings
- `"fo"` and `"o"` should hash differently than `"f"` and `"oo"`.
3. Fixes hashes of enums
- `Foo::Bar(1)` should hash differently than `Foo::Baz(1)`
4. Standardizes `usize`/`isize` as 8 bytes
Since we used to build the HTML using our own `<Document>` component, we
were previously adding a data-turbopack-chunk-id attribute to our
`<link>` tags to reconcile chunk paths with their chunk ids when
initializing HMR. However, Next.js is now responsible for building the
HTML, and it has no such mechanism.
**NOTE:** HMR is currently broken for non-Next-SSR rendering
(HtmlAsset). This PR does not fix that.
* remove 100 modules form the default modules count
* rename bench_restart -> bench_hydration_cached
* add bench_startup_cached
* run npm install only once per test case and copy the result instead
* use multi-threaded copy
* Run `cached` tests only when `TURBOPACK_BENCH_CACHED` is set
* add `TURBOPACK_BENCH_BENCH` too measure the time it takes to run the
full benchmark (including startup and teardown) instead.
* add `TURBOPACK_BENCH_HEAD` to run non-headless
* add `TURBOPACK_BENCH_DEVTOOLS` to auto open devtools
* retry initial warmup change when it fails to detect that
This should make the benchmarks about 3 times faster... at least on
windows^^
Rebase of vercel/turbo#68, which was merged into a now-closed PR.
Closesvercel/turbo#65.
When configured to use preset-env, this stops turbopack from inserting
dependencies on core-js. It's:
* Buggy/error-prone, at least through swc preset-env:
* https://github.com/vercel/the-three-body/issues/65
* setImmediate "polyfills" always inserted for this nonstandard feature
when
React (scheduler, iirc) does feature detection of it
* Big. Updating the snapshot alone for a test that only used [].includes
resulted in a diff with nearly 4700 line deletions
* Not done by Next.js for modern targets in the past couple of years:
https://twitter.com/timneutkens/status/1234548900272517120
Test Plan: Added [].includes to preset_env snapshot test and verified no
references to core-js are inserted.
This will remove the warning about using `hydrate` instead of
`hydrateRoot`, and fix a mismatch between SSR and CSR when using
styled-jsx (`<style jsx>`).
We can't use the normal `ImportMap` because we stop resolving if looking
up a request within yields a result. However, for module polyfills, we
only need to look up the request when normal resolving fails. Hence the
dichotomy between the `import_map` and the `fallback_import_map`.
In a more modular architecture, we would model this as a stack of three
resolvers:
1. ImportMapResolver
2. DefaultResolver
3. FallbackImportMapResolver
I'm guessing this is what we'll have in the future, but this requires a
bigger refactoring than what I'm comfortable with implementing for now.
This PR also includes the changes in vercel/turbo#12
This optimizes Next.js SSR by marking `react[/*]` and `next[/*]` imports
as externals in Node.js, which means that they will be `require`d
directly instead of bundled.
This optimization reduces the number of modules to analyze on the server
for a single component app from ~1000 (Next.js SSR imports a lot of
modules, including amp-optimizer which includes more) to <10.
Co-authored-by: Tobias Koppers <tobias.koppers@googlemail.com>
add very simple explorer to introspect the graph via `/__turbopack__/`
Allows to "walk" through the content sources and asset graph. Some
assets allows to access inner assets, e. g. from the ecmascript chunk
you can access the entry module asset, so you can go a level deeper.
It works by a `Introspectable` trait which can be implemented by
anything we want to allow the user to inspect. In future the in browser
UI should offer a nice UI to explore your application.
In future we probably also want to add some `metrics` to the
`Introspectable` trait, e. g. to report size of an asset.
This UI is very basic currently, but that works for debugging:
It's important to not create a `cell` outside of the root `source` method as this will create a new cell for each call, which means each `source` will create a separate task, and this bubbles for each cell created in `source`...
This makes the argument to `embed_file!` relative to the package it is invoked from, instead of relative to the file it is invoked from. The latter is closer to how `include_*!` works, but it has a couple of issues:
* Since `file!` returns a path relative to the workspace, it requires knowing the full path to the workspace. However, this is undefined when the package is compiled from outside of the workspace (e.g. as a dependency of another package).
* Procedural macros don't have access to the path of the file where they were originally invoked [(although we could get it with #[feature(proc_macro_span)])](https://doc.rust-lang.org/proc_macro/struct.Span.html), which means that an `embed_dir` macro would not be able to be relative to the invoker file anyway. So this makes things more consistent for such a (to be implemented) macro.
