-
Notifications
You must be signed in to change notification settings - Fork 231
feat(next): Allow specifying workflow directories #1159
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,5 @@ | ||
| --- | ||
| "@workflow/next": patch | ||
| --- | ||
|
|
||
| Allow specifying workflow directories |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -264,6 +264,45 @@ Check the [Deploying](/docs/deploying) section to learn how your workflows can b | |
|
|
||
| ## Troubleshooting | ||
|
|
||
| ### Out of Memory (OOM) during build | ||
|
|
||
| When using `withWorkflow()` in a large Next.js application, the "Discovering workflow directives" phase may consume excessive memory, causing builds to fail with OOM errors on standard build machines (e.g., 16 GB RAM). | ||
|
|
||
| **Solution:** Use the `workflows.dirs` option to point directly at the directories containing your workflow files. By default, `withWorkflow` uses entrypoint directories (`pages`, `app`, `src/pages`, `src/app`) as starting points and traces their imports to discover workflows, which in large applications can involve crawling thousands of files. | ||
|
|
||
| If your workflows live in a dedicated directory, configure `dirs` to only scan that directory: | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. the other problem with "dirs" is that it causes split brain I think: the client mode/webpack transformation still has to happen in the actual code (api routes/server actions) that trigger workflows. we can't skip that - and that code won't live in the workflows directory
|
||
|
|
||
| ```typescript title="next.config.ts" lineNumbers | ||
| import { withWorkflow } from "workflow/next"; | ||
| import type { NextConfig } from "next"; | ||
|
|
||
| const nextConfig: NextConfig = {}; | ||
|
|
||
| export default withWorkflow(nextConfig, { | ||
| workflows: { | ||
| // Only scan the workflows directory instead of the entire app | ||
| dirs: ['workflows'], // [!code highlight] | ||
| }, | ||
| }); | ||
| ``` | ||
|
|
||
| If your workflows are spread across multiple directories: | ||
|
|
||
| ```typescript title="next.config.ts" lineNumbers | ||
| import { withWorkflow } from "workflow/next"; | ||
| import type { NextConfig } from "next"; | ||
|
|
||
| const nextConfig: NextConfig = {}; | ||
|
|
||
| export default withWorkflow(nextConfig, { | ||
| workflows: { | ||
| dirs: ['workflows', 'src/background-jobs'], // [!code highlight] | ||
| }, | ||
| }); | ||
| ``` | ||
|
|
||
| This significantly reduces memory usage and build times by avoiding scanning unrelated application code. | ||
|
|
||
| ### Next.js 16.1+ compatibility | ||
|
|
||
| If you see this error when upgrading to Next.js 16.1 or later: | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -41,7 +41,7 @@ export class LocalBuilder extends BaseBuilder { | |
| watch: nitro.options.dev, | ||
| dirs: ['.'], // Different apps that use nitro have different directories | ||
| }), | ||
| buildTarget: 'next', // Placeholder, not actually used | ||
| buildTarget: 'standalone', // Placeholder, not actually used | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 'standalone; means something else. this could be
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. unless this was needed for some reason?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It complained about the missing |
||
| }); | ||
| this.#outDir = outDir; | ||
| } | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we should do dirs (for other reasons - like @ijjk mentioned - the lazy approach is the correct answer here).
but if we were to do dirs or add new configs, we shouldn't be putting it in a enw config options at the end of
withWorkflowI think. instead the signature of withWorkflow should becomewithWorkflow(NextConfig & { workflow: WorkflowConfig })imo (including the local port/datadir options and future config options)There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the lazy approach works, then sure, I'll use it. Just began testing it again.
But what would the call to
withWorkflowlook like then? Keep in mind that the config might be a function, so we can't easily pass{...nextConfig, workflow: {...}}. Putting the option in the "raw" object literal would require typing it asNextConfigOrFn & WorkflowConfig, which again wouldn't work for functions and would be an extra step. I don't see what's wrong with the current signature,withSentryConfigdoes it the same way. Maybe Next.js could give an easier way for multiple modules to add config, but then you'd also need to care about namespaces, ...