Co-authored-by: Anthony Shew <anthony.shew@vercel.com>
Co-authored-by: Jared Palmer <jared@jaredpalmer.com>
Co-authored-by: Maia Teegarden <dev@padmaia.rocks>
Co-authored-by: Will Binns-Smith <wbinnssmith@gmail.com>
Co-authored-by: Alex Kirszenberg <alex.kirszenberg@vercel.com>
Co-authored-by: Matt Pocock <mattpocockvoice@gmail.com>
* Store the sourcemap::SourceMap directly, instead of encoding it
* Implement GenerateSourceMap trait and use it to retrieve live maps
* Cleanup and comments!
* Update safety comment
* Rename var
* Update snapshots
* Update snapshots
* Fix tracing errors in SSR
SSR has access to `EcmascriptChunkVc`, not `EcmascriptChunkContentVc`. Client gets access only to `EcmascriptChunkContentVc`
* Fix source map sources on client
Because the JS is nested in dirs, the source needs to be an absolute path.
Co-authored-by: Jared Palmer <jared@jaredpalmer.com>
* Fix unused question marks warnings
Fix some return types that were giving clippy warnings, mostly `needless_question_mark`.
Remaining warnings are either `too_many_arguments` or `type_complexity`.
* Fix unncessary let binding
Co-authored-by: Justin Ridgewell <justin@ridgewell.name>
Instead of using stdout for communication between the Node.js process
and the Turbopack instance, this PR switches to a TCP connection.
Furthermore, stdout and stderr are now piped between the Node.js process
and Turbopack.
Because the static SSR renderer doesn't emit files that exist in
`node_modules` (because we take advantage of node's native `require`
resolution), any paths that traced into `node_modules` would output the
full file system path. It's just verbose and annoying.
Co-authored-by: Tobias Koppers <tobias.koppers@googlemail.com>
This makes turbopack automatically create `app/layout.js` if
`app/page.js` exists, or `app/layout.tsx` if `app/page.tsx` exists, and
neither layout file already exists.
**Note that I'd prefer this issue to have info severity, but even with a
higher log level of info, the issue is never shown**. Filed vercel/turbo#265 to
track this.
Test Plan:
In a new `create-next-app`, opt into appDirectory and create
`app/page.js`. Run turbopack and verify:
* [x] the index page renders correctly
* [x] An issue with Warning level is logged notifying the user an
`app/layout.js` was created
* [x] `app/layout.js` is actually created with basic root layout
In a new `create-next-app`, opt into appDirectory and create
`app/page.tsx`. Run turbopack and verify:
* [x] the index page renders correctly
* [x] An issue with Warning level is logged notifying the user an
`app/layout.tsx` was created
* [x] `app/layout.tsx` is actually created with basic root layout
In a new `create-next-app`, opt into appDirectory and create
`app/page.tsx`. Also create a basic `app/layout.js` (note js layout with
tsx page). Add a custom `<title>` to the layout. Run turbopack and
verify:
* [x] the index page renders correctly
* [x] No issue is logged
* [x] No files are modified
* [x] The custom `<title>` is reflected.
This adds the Next SSG transform. This transform does a few things, but
the one we're most interested in right now is the removal of
`getStaticProps`/`getServerSideProps`/etc. from page modules. HMR will
be disabled if these exports are preserved.
Co-authored-by: Tobias Koppers <tobias.koppers@googlemail.com>
Seems like app layout was left behind while shipping features to normal
SSR rendering
* fixes fallback error pages (update to error fallback changes)
* fixes process communication (update to api route changes)
* avoid busy looping
* update to next.js updates
* fix resolving cycle
* fix HMR of client components
* add some hard coded external packages
Enabled in next-dev and snapshot tests.
There are quite a few output snapshot files. Maybe we make stubs for the
third-party packages to reduce the noise...
Test Plan: Added new snapshot tests. Verified transformed code contains
a digest, inline source map string.
This reworks our Node.js rendering logic to allow for:
* passing binary request bodies in and out of Node.js: API routes can
accept request bodies in POST, and can reply with any content type.
* content source results that are recomputed every time: we don't want
API routes to be cached (at least not by turbopack for now).
It also reworks the `END_OF_OPERATION` logic to avoid hard coding a
single end of operation marker (they're now unique per pool), and allow
multiple kinds of operation events (`Step`, `Success`, `Error`).
This is not a particularly good implementation for this. A better
implementation would proxy the request from the client to the Node.js
server in a more direct manner. We also need a way to tell turbo tasks
"don't bother ever caching this", as right now every single API request
and result will still be cached, even if we know they will never be used
again. Finally, we should communicate with Node.js processes via a
better mechanism than stdout. I made some progress on a prototype for
using https://github.com/servo/ipc-channel with NAPI a while back, which
I'd like to pick up some time after conf.
However, it seems to work well enough for now, so yay.
Co-authored-by: Tobias Koppers <tobias.koppers@googlemail.com>
Closesvercel/turbo#109
Note a difference between this and stable Next.js: at turbopack this
file is placed in .next/server/package.json, while Next.js currently
creates this file at .next/package.json.
Test Plan: Verified that the `hello-world-esm` no longer fails to SSR
(it's now blocked by vercel/turbo#111).
Co-authored-by: Tobias Koppers <tobias.koppers@googlemail.com>
