Force close process after build / prepare commands

[enkot]

Environment

• Operating System: Linux
• Node Version: v16.20.0
• Nuxt Version: 3.7.0
• CLI Version: 3.7.2
• Nitro Version: 2.6.2
• Package Manager: [email protected]
• Builder: -
• User Config: modules, routeRules, hooks
• Runtime Modules: @nuxt/[email protected]
• Build Modules: -

Reproduction

https://stackblitz.com/edit/github-c8qlr3?file=server%2Fplugins%2Ftest.ts

Describe the bug

If we add the page to routeRules (prerender: true) and start some timer/listener in the Nitro plugin, the process does not close after the build.
Also nitro.hooks.hook('close', () => {}) will never be called.

Additional context

It was working fine on Nuxt 3.6.5.

Temporary workaround (UPDATED):

export default defineNuxtConfig({
  hooks: {
    close: (nuxt) => {
      if (!nuxt.options._prepare)
        process.exit()
    }
  }
})

Logs

No response

[stackblitz]

Start a new pull request in StackBlitz Codeflow.

• github-c8qlr3 (Open reproduction)

[danielroe]

cc: @pi0

[tobiasdiez]

Thanks for the workaround. It works well except that nuxi prepare no longer writes types. This can be resolved by slightly modifying the workaround to:

  hooks: {
    close: (nuxt) => {
      if (!nuxt.options._prepare) {
        process.exit()
      }
    },
  },

[danielroe]

~> #185

[tobiasdiez]

@danielroe I'm not sure if they are indeed the same issues, for me nuxi build hangs and but nuxi prepare works (my remark above concerning prepare was only about an issue with the hotfix)

[danielroe]

I'll leave it open for now then, pending further triage 👌

[enkot]

@danielroe This issue still exists on Nuxt 3.7.3 and has nothing to do with nuxi prepare.

[danielroe]

Yes, the root issue in the linked issue is not actually related to the prepare command

[pi0]

This is a behavior change since we migrated to the new CLI infra. Previously we were "force closing" the process in case to prevent hanging handlers/listeners.

Modules should probably close their handler via close hook and we were silently doing this before.

I think we should add it back with also an explicit warning. But also only do it when using nuxi as CLI and not force exit for programmatic usage.

[davestewart]

Any movement on this? Does Nuxt 3.8 solve these issues?

[michalkuncio]

@davestewart unfortunately not. Tried it on 3.8 release day and the process is still hanging :(

[davestewart]

@pi0 this is a blocker for various modules including Nuxt Content Assets.

Projects which use these modules will be unable to update to the latest and greatest Nuxt.

Can you provide some comment or roadmap to resolution?

Would it be worth adding a close hook to the module as mentioned here?

Thanks

[santiagoaloi]

has this been resolved or do I need to use this workaround still?

[notthetup]

Nope. Seems like still unresolved even on the latest release. :(

[danielroe]

For anyone still encountering this, a reminder that this typically occurs because of non-Nuxt code, typically within modules, but it can be anything that leaves something un-cleaned-up, such as a watcher.

I apologise for it taking so long, but I did eventually 🙈 take a look at Dave's module and prepared this PR, linked in case it's useful for anyone: davestewart/nuxt-content-assets#65.

I did look into it further and also found this issue with Nitro, which was likely also at play: unjs/nitro#2287

After that merges, I think we can close this issue, but if you're still encountering something like this in your project after that point, please open a new issue with a reproduction and I'll happily look into it further 🙏

[pi0]

You can try the prerenderer fix using nightly release channel as @danielroe summarized this issue most of the times happens due to open handlers or watchers in modules.

[davestewart]

Great work (as usual) @danielroe!

I might also suggest to add some additional documentation around this.

Often as a module developer we're just focused on mainly getting something to work (i.e. the watch) and may either not think about the unwatch, or just not know enough about the wider context of the difference between build, dev, or in this case some change between Nuxt versions, which would blow up at some later date.

If – as a core developer – you suspect a footgun, please document to the lowest common denominator!

I can see that unwatch is documented, but in the bowels of developing a Nuxt plugin, triggered by Nitro, and leveraging unstorage, could there be any way to preempt showstoppers like this?

Maybe a gotchas or best practices for module developers in Nuxt docs?

Or, is the cycle of bugs > issues > debugging > repeating, etc just the way it is ?