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.
This is a very simplified version of what Next.js does. It adds support for `App` and page components defining `getInitialProps`.
fixesvercel/web-tooling-internal#38
This updates all of our Issues to have a consistent display, and changes the way we display source code and debug-level details. In particular, this makes the following changes:
1. Cleans up the title/description of existing issues
- We were filling the `title` field with too much information, because the `desccription` field wasn't always shown.
1. Always displays the `description`
- This used to be hidden behind the `--detail` flag
1. Always displays the code frame of the issue, if it exists
- This used to be hidden behind the `--detail` flag
1. Fixes the `context` (file path) to display the relative path to the file
- It was hardcoded to the FS string used by turbotrace
1. Creates a new `detail` function which can provide debug-level information about the internal Rust state
- This is not shown by default, user must pass `--detail` flag
The format for a rendered issue roughly matches:
```
${SEVERITY} [${CATEGORY}]
${CONTEXT}
${TITLE}
${CODE FRAME}
${DESCRIPTION}
${DETAIL}
```
Where
- `SEVERITY` is error/warning/etc
- `CATEGORY` is a self-defined string for the phase of the compiler (eg, "parsing", "running")
- `CONTEXT` is a file path to the offending file
- `TITLE` is a short (single-line) title
- `CODE_FRAME` is an optional position that generated the issue, which will display a few context lines and highlight the offending span of code
- `DESCRIPTION` is a longer (multi-line) message that describes the issue, and what to do about it
- `DETAIL` is a (by default not shown) fully detailed, debug-level, message providing insights into the internal state of Rust
This adds preliminary support for pages/_document. The API is more complex than pages/_app, so this required a few more things in order to work.
Right now, our `next/document` shim does much, much less than the original. We will eventually have to figure out whether we should distribute our own module, or find a way to reuse Next.js' internals. There's *a lot* of stuff in there so the second option is probably best.
This adds preliminary support for pages/_app. There's still some work to do here to support things like `App. getInitialProps`, etc., but that will come in later PRs. I've created issues for these for now.
One issue remaining is that renaming `pages/_app.js` does not switch to the default _app asset. The server needs to be restarted for this to happen. Similarly, adding an _app.js file does not switch from the default asset to it. I'm guessing there's something wrong with the way I set up the import mappings, and they aren't being invalidated properly?
fixesvercel/turbo#424
remove context_path from AssetContext
remove most with_* methods from AssetContext
add ResolveOrigin trait
use ResolveOrigin to pass along context path and context for resolving
ecmascript and css module assets implement ResolveOrigin
Noteable change: Many places use `origin_path` instead of `context_path` which means it points to the issuer module path instead of the issuer module directory.
Closesvercel/turbo#440
This uses swc's preset_env to automatically downlevel code according to the environment's browser targets, and sets next-dev to use a limited, modern target.
To do:
* [x] Add snapshot test
* [x] turbotrace test failures — looks like this has something to do with the Buffer module? Hitting swc's "multiple constructors" not implemented: f655488cfa/crates/swc_ecma_transforms_compat/src/es2015/classes/mod.rs (L545)
* [x] ~Benchmark downleveling node_modules (probably on front) and make a decision re: downleveling everything vs. just workspaces~ Filed as vercel/turbo#457
Wrapper is a bit of a weird name since it's not actually wrapping the existing asset. Actually it's just a virtual asset with a path below the existing path.
* Fix DiskFileSystem::read_link
* pnpm-like integration test
* Introduce AssetContent to handle symlink assets
* Fix read_link on Windows
* Run clippy fix
* Rename `path` to `target`
Co-authored-by: Justin Ridgewell <justin@ridgewell.name>
* Split Windows specified code
* Add comments about Redirect is only represent Directory
* Handle symlink while reading content
* Clippy fix
* Revert previous changes in FileSystemPathVc::get_type
* Fix Unix read_link
* cleanup
* handle symlink while resolving native bindings
* Make LinkContent::Link contains only target
* Add LinkType to represent link type
* Cleanup VersionedAsset
* Cleanup LinkType
* Normalize the LinkContent::target
* Comments
* Revert special case workaround for sharp on Windows
* comments
* node_native_binding follow file link
* Apply CR suggestion
Co-authored-by: Justin Ridgewell <justin@ridgewell.name>
This implements `.env` loading by taking advantage of the [dotenvy](https://docs.rs/dotenvy/latest/dotenvy/) crate. Unfortunately, this isn't as featureful as the npm `dotenv`, lacking `FOO=${BAR:-default}` default support (this might be important), `FOO=${MAYBE_UNDEFINED:-${BAR-:default}}` nested fallbacks, and `` FOO=`backtick` `` support.
This is then converted into a series of assignments for the client code. This is run before any of the user code.
```js
const env = process.env;
env["FOO"] = "bar";
//...
```
- - -
TODO:
- [x] ~~Replace `process.env.FOO`/`process.env["FOO"]` during chunk compilation~~
- using a runtime module speeds up HMR because the code doesn't need to be recompiled.
- [x] I don't actually know how to test server rendering, so I assume it works but haven't verified.
moves the logic of creating SourceMap assets into the asset reference. This avoids depending on the chunk items in the references() method directly. It also avoids calling CodeVc::source_map() until the source map is read
avoid circular dependency in call graph
It also avoids checking `has_source_map()` and just inserts potential Source Maps assets for every chunk item. Checking `has_source_map()` seems unnecessary work to do for all chunk items, when we can just send an empty source map.
only expose SourceMaps for chunk items when HMR is enabled
picked typescript transform from https://github.com/vercel/turbo-tooling/pull/341
add resolve options context as global resolve config
enable typescript only for next-dev
move emulating logic from environment to resolve options context
Co-authored-by: Leah <8845940+ForsakenHarmony@users.noreply.github.com>
This implements support for styled-jsx in next-dev using swc's styled_jsx crate.
It's only applied in next-dev, and is only applied as a transform to app code, much like the react-refresh transform.
To do:
* [x] The transform doesn't seem to be applied. Pass the added test.
Test Plan: `cargo test -p next-dev --
test_crates_next_dev_tests_integration_turbopack_basic_styled_jsx
--nocapture`
Remaining questions:
* Should we have some static analysis for `getStaticProps` instead of looking into exports at runtime?
* For now, the output of `getStaticProps` (if defined) will always trump the value passed in as `data`. If we consider `data` to be the cached output of `getStaticProps` (in the future, as this is not yet implemented), this logic should be adapted.
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?`.
This PR implements HMR support with React Refresh built-in.
For now, in order for React Refresh to be enabled, you'll need the `@next/react-refresh-utils` package to be resolveable: `yarn add @next/react-refresh-utils` in your app folder.
* Depends on vercel/turbo#266
* Integrated both HMR-and-React-Refresh-specific logic directly into the ES chunks' runtime. Webpack has more complex setup here, but for now this makes the logic much more easy to follow since everything is in one place. I have yet to implement the "dependencies" signature for `hot.accept`/`hot.dispose`, since React Refresh does not depend on them. We'll have to see if they're even used in the wild or if we should deprecate them.
* Only implemented the [module API](https://webpack.js.org/api/hot-module-replacement/#module-api), not the [management API](https://webpack.js.org/api/hot-module-replacement/#management-api). We apply all updates as soon as we receive them.
* Added support for "runtime entries" to ES chunks. These are assets that will be executed *before* the main entry of an ES chunk. They'll be useful for polyfills in the future, but for now they're here to evaluate the react refresh runtime before any module is instantiated.
Next steps for HMR:
* Implement CSS HMR
* Implement (or decide to deprecate) the [dependencies form](https://webpack.js.org/api/hot-module-replacement/#accept) of `hot.accept`/`hot.dispose`
* Clean up `runtime.js` some more: switch to TypeScript, split into multiple files, etc. It'd be nice if all of this could be done at compile time, but how to achieve this is unclear at the moment. _Can we run turbopack to compile turbopack?_
Server Rendering:
* This adds an additional ContentSource to next-dev which takes care of handling the `pages` directory.
* The content source creates a ServerRenderedAsset from each file in the `src/pages` or `pages` directory and a AssetGraphContentSource for that.
* The ServerRenderedAsset will reference an underlying asset for the node.js context which will be passed to the node executable for rendering. It uses a WrapperAsset to add additional communication logic.
Client Transition:
* When annotating `import`s with `transition: "next-client"` the NextClientTransition is used
* This transition changes the environment to browser
* It wraps the referenced asset with a next-hyrdation wrapper asset
* It leaves a little module in the previous context which exports a list of URLs for chunks needed.
* The NextClientTransition takes a client_chunking_context as argument which specifies how the client code is chunked.
