Creates a new workflow and action that auto labels with `linear` whenever we apply `kind: bug`.
It's using JS action instead of docker, so it should be quite fast.
I tested this on my fork and it works.
Also created the action with TS so we can use it as a starting point for next actions so they can all be typed.
- Unify logging in test startup
- Added simple custom server test
It's testing just simple page serving in production mode.
Co-authored-by: Tim Neutkens <6324199+timneutkens@users.noreply.github.com>
When using standalone output in a monorepo, nextjs will sometimes throw:
`> NX ENOENT: no such file or directory, open
'/dist/apps/my-app/.next/standalone/apps/my-app/server.js'`
next.config.js:
```js
const { withNx } = require("@nrwl/next/plugins/with-nx");
const path = require("path");
/**
* @type {import('@nrwl/next/plugins/with-nx').WithNxOptions}
**/
const nextConfig = {
output: "standalone",
experimental: {
outputFileTracingRoot: path.join(__dirname, "../../"),
},
};
module.exports = withNx(nextConfig);
```
## Bug
- [x] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have a helpful link attached, see
[`contributing.md`](https://github.com/vercel/next.js/blob/canary/contributing.md)
Fixes https://github.com/nrwl/nx/issues/14112,
https://github.com/nrwl/nx/issues/9017
This `mkdir` instruction is the same as done for other parts of the
`copyTracedFiles` function. E.g. middlewares or pages.
Tested via publishing to an internal npm registry and pnpm overrides:
```json
"pnpm": {
"overrides": {
"next": "npm:@internal/next@13.1.3-dev"
}
}
```
Co-authored-by: Tim Neutkens <tim@timneutkens.nl>
Co-authored-by: Steven <steven@ceriously.com>
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
Before migrating "loadable" the from js to ts, the reload-ready function initialized its "ids" parameter with an empty array. The migration step added the parameter type but removed the initialization.
Providing an empty array as the default value for the ids parameter is necessary; otherwise, the ids variable in the createLoadableComponent function, line 102, gets undefined, and the loading of components fails.
fixes#44695
Previously we were targeting lower versions of Node.js for `app` directory support, but a higher version of Node.js (with support for `AsyncLocalStorage`) was made required to use `undici` instead of `node-fetch`. This PR serves to:
1. Simplify the usage of those storage objects by removing the unnecessary fallback code. Everything now just uses the native `AsyncLocalStorage` interface.
2. Isolates the initialization of each store within it's own bound context to prevent leakage.
3. Adds immutibility flags to variables that should only be initlaized once upon store creation to prevent errors. This actually revealed some bugs in the implementation that were corrected.
In the event that this was in error, the following adapter could be used to simulate the previous beheviour with minor changes to the present implementation ([see this gist](https://gist.github.com/wyattjoh/6f3dffb99a4ac1a8254c90284f05026a)).
[Slack Reference](https://vercel.slack.com/archives/C04DUD7EB1B/p1673030967568029)
Adds support for rendering MDX as a Server Component.
The main reason a MDX file couldn't be rendered as a Server Component is
that `@mdx-js/react` has a legacy/deprecated context setup in the file.
Because of calling `React.createContext` the MDX file couldn't be a
Server Component.
I've added support for a special file `mdx-components.tsx` (or `.js`) at
the root of the project (can be `src` dir too).
By using mdx-components you don't need a global context provider which
in turn makes MDX compatible to be rendered as a Server Component.
Note: this changes `@next/mdx` to add support for that file so it has to
be landed first before the example works.
<!--
Thanks for opening a PR! Your contribution is much appreciated.
To make sure your PR is handled as smoothly as possible we request that
you follow the checklist sections below.
Choose the right checklist for the change that you're making:
-->
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have a helpful link attached, see
[`contributing.md`](https://github.com/vercel/next.js/blob/canary/contributing.md)
## Feature
- [ ] Implements an existing feature request or RFC. Make sure the
feature request has been accepted for implementation before opening a
PR.
- [ ] Related issues linked using `fixes #number`
- [ ]
[e2e](https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs)
tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have a helpful link attached, see
[`contributing.md`](https://github.com/vercel/next.js/blob/canary/contributing.md)
## Documentation / Examples
- [ ] Make sure the linting passes by running `pnpm build && pnpm lint`
- [ ] The "examples guidelines" are followed from [our contributing
doc](https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md)
Co-authored-by: JJ Kasper <jj@jjsweb.site>
Make templates actual executable tests to that we ensure there are no regressions.
It also makes the setup easier.
Also changes the layout to typescript because that's what we want to use by default anyway.
Also refactors helper function to use plop specific `{{ toFileName name }}` syntax for easier template modification.
Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
## 📖 What's in there?
With Edge Function GA for API Routes, it would make sense to suggest
developer to change their runtime key from `experimental-edge` to
`edge`.
Current behavior is:
1. when using `experimental-edge` in API route:
> prints a warning _once:_ `warn - You are using an experimental edge
runtime, the API might change.`
1. when using `experimental-edge` in pages:
> prints a warning _once:_ `warn - You are using an experimental edge
runtime, the API might change. `
1. when using `edge` in pages:
> throws an error _for each page_: `error - Page /xyz provided runtime
'edge', the edge runtime for rendering is currently experimental. Use
runtime 'experimental-edge' instead.`
This PR adjust case # 1 to indicates which API file is using
`experimental-edge` (a warning per page), and suggest to migrate:
`warn - /pages/api/xyz provided runtime 'experimental-edge'. It can be
updated to 'edge' instead.`
- [x] Integration tests added
## 🧪 How to test?
Besides running e2e tests with `NEXT_TEST_MODE=dev pnpm testheadless
--testPathPattern edge-configurable-runtime`, you can create a test app
in `examples` folder:
```jsx
// examples/edge-warnings/pages/api/edge.js
export default () => new Response('ok')
export const config = { runtime: 'experimental-edge' }
// examples/edge-warnings/pages/index.jsx
export default () => <p>hello world</p>
export const runtime = 'experimental-edge'
```
Build next.js then run with `pnpm next dev examples/edge-warnings`.
You can try adding more pages with `experimental-edge` runtime (will not
produce more warnings), adding more API with `experimental-edge` (will
produce new warnings), or change page runtime to `edge` (will produce
errors).
I copied the middleware example from the docs to ignore a few matches but the optimized images stopped working. I figure that it was missing adding in the Regex of my middleware.
## Documentation / Examples
- [x] Make sure the linting passes by running `pnpm build && pnpm lint`
