rollup -c not quit after created bundle

[sunshineplan]

Rollup Version

2.56.3

Operating System (or Browser)

windows-latest, ubuntu-latest, macos-latest in github actions

Node Version (if applicable)

16.8.0

Link To Reproduction

https://github.com/sunshineplan/sda/actions/runs/1174174007

Expected Behaviour

rollup quit after created bundle, so other github actions will go on.

Actual Behaviour

rollup hang up after created bundle

[phuocng]

I faced the same issue: rollup 2.56.3 on macOS 11.5.2, NodeJS 14.17.5

[theplayer06]

I have same issue in wsl2 - window 10

[laurentpayot]

Same issue on Ubuntu 21.04 with node 15.11.0

[vvinogradsky]

Same here on Windows 10

[nicholas-ochoa]

Same issue here. I noticed it seemed to be (at least in my case) related to the version of TypeScript. When I upgraded to 4.4.2 (latest as of right now). I downgraded to TypeScript 4.3.5 and it seemed to resolve my problem.

Occurring on Windows 10, WSL (Debian) and Linux (RHEL 8.4) - all using Node 14.17.5

[revelt]

It seems the problem is with cli.js — it never exits (but only on certain environments, not everywhere):

This run(command) here

rollup/cli/cli.ts

Line 23 in 81fa9e9

run(command);

Gets transpiled into runRollup(command):

...
else {
    try {
        require('source-map-support').install();
    }
    catch (err) {
        // do nothing
    }
    runRollup(command);
}

The runRollup() above is an async function and it needs to be manually exited!

If this error happens on your local machine, you can try editing node_modules/.bin/rollup and appending the .then(() => process.exit()); like this:

runRollup(command).then(() => process.exit());

Try. It's more difficult to do on a CI of course but still possible.

My research so far

• It's not the Node version, I tried all versions
• Issue is not happening on rollup-starter-lib on my machine (M1 Mac) — so rollup -c process goes zombie only on certain setups, not everywhere
• It's got something to do with monorepo in my case (wiping lerna-generated node_modules and cding into one of packages and npm i solves the problem, rollup builds fine — but it's monorepo, long-term I can't short-circuit packages like that!)
• It's not ES modules ("type": "module") or exports or anything to do with CJS being one of build targets

[sunshineplan]

Same issue here. I noticed it seemed to be (at least in my case) related to the version of TypeScript. When I upgraded to 4.4.2 (latest as of right now). I downgraded to TypeScript 4.3.5 and it seemed to resolve my problem.

Occurring on Windows 10, WSL (Debian) and Linux (RHEL 8.4) - all using Node 14.17.5

Actually, I met this problem because of upgrading TypeScript by dependabot. I noticed it has some break changes.
https://devblogs.microsoft.com/typescript/announcing-typescript-4-4/#breaking-changes

[phuocng]

Downgrading TypeScript from 4.4.2 to 4.3.5 fixes the issue for me.
Thanks @sunshineplan and @nicholas-ochoa

[lingxiao-Zhu]

use rollup-plugin-typescript2 instead of rollup-plugin-typescript2

[sunshineplan]

Also see rollup/plugins#983
microsoft/TypeScript#45642 fixed this problem, new release will be ok.

[sunshineplan]

Fixed with TypeScript 4.4.3

[mattxyzeth]

I'm facing this problem. Typescript 4.6.3. @revelt is correct that this method needs to be awaited or completed with a then callback. How does Typescript affect this?

[revelt]

@mattxyzeth if I may advise,

1. rule out basics — ensure you actually have the latest ts and rollup — check versions inside node_modules (or npm ls)
2. double-check rollup plugins, are any out of date — if possible try disabling one-by-one
3. try manually tweaking rollup cli inside node_modules/bin, add exiting runRollup(command).then(() => process.exit());
4. build the proof case — try to recreate the MVP case to prove it's happening — strip your project to just intact rollup config and replace sources with a trivial function, strip any branding or sensitive info — post on stackblitz and share the link — we might have to reopen this ticket.

is correct that this method needs to be awaited or completed with a then callback

At least back then, when we were facing the problem, correct, that's what worked — but I rolled back my dependency bumps and waited it out until 4.4.3 (and eventually migrated to esbuild).

How does Typescript affect this?

If you mean the bug, it could have been anything. Typescript is a whole ecosystem — AST's, mapping of what-in-TS gets transpiled to what-in-JS and so on. For example, zalgo could have been released in the transpiled output. I don't know.

Personally, since, I migrated from rollup to esbuild for bundling, I use rollup only for generating .d.ts. See for example here and here.

[mattxyzeth]

I'm not entirely convinced it's related to TS. My app has two builds—one for the app and one for the service workers. The build always hangs in my local environment for the app and never for the workers. On my CI server, it only hangs once in a while for the app and never for the workers.

As for your suggestions, I've ruled out the first two. The most stable combination is if I downgrade TS to 4.4.3, but it fails intermittently. Everything always works with any version if I apply the patch in number 3. I'm wondering why this isn't used as the default. Is there a downside to adding this?

EDIT: I upgraded all my rollup plugins that were not in common between my service worker's config and my app config. I also upgraded TS to the latest version. The build started exiting properly in my local environment. So I tried to mimic the exact same environment on my CI server except for the OS but it's still failing there. Then after a few tries in my local environment, it started to hang again, without any changes.

[mattxyzeth]

We've tracked down our issue to an unrelated animation package imported into our bundle. So it seems that this issue extends beyond the plugins. We don't have a clear idea of why this package was causing the build to not exit. The build completes successfully but doesn't exit 100% of the runs. We saw an average of a 30% success rate across multiple computers and environments. Unfortunately, I don't think that the patch mentioned in this thread is the ultimate solution since the problem could indicate a much larger issue in the bundle and not directly related to the build process. Maybe there should be some timeout error that means something was left hanging that has caused the build not to exit correctly.

[krohrsb]

We ran into this when leveraging rollup in a RushJS monorepo. Multiple builds happening at the same time. When building the monorepo we would get rollup not exiting after building a package, on various packages (nothing deterministic). This was very common and very reproducible.

I tested the proposed solution from #4213 (comment) and this has seemingly solved the problem. Likely exasperated by multiple processes/concurrency?

I've got a local PNPM patch to test it more long term at the moment.

[isc30]

Wow we have exactly the same issue with RushJs, can you share more details about your fix/patch please? Thanks a lot!

[krohrsb]

Wow we have exactly the same issue with RushJs, can you share more details
about your fix/patch please? Thanks a lot!

I use pnpm and so used https://pnpm.io/cli/patch in order to persist the change suggested by the comment I linked to in my previous reply. It's not a long term fix. Perhaps roll-up will accept a contribution.

[lukastaegert]

Sorry for completely missing this issue. While I cannot reproduce it, adding the proposed force exit should not pose any problems, I will put it into the next release.

[lukastaegert]

Please check out #4969

[rollup-bot]

This issue has been resolved via #4969 as part of rollup@3.21.3. You can test it via npm install rollup.

[chordmemory]

Can we reopen this @lukastaegert? It looks like the fix has been reverted.

[chordmemory]

@lukastaegert I've had success using the same workaround from the revert pr.

For anyone struggling with this, but needing to intake new rollup versions, try adding this as the last plugin in your plugin array in rollup.config.js :

{
    closeBundle() {
        if (!process.env.ROLLUP_WATCH) {
          setTimeout(() => process.exit(0));
        }
    },
    name: 'force-close'
}

[jhanssen]

@chordmemory thanks, I've been banging my head against this for the last couple days and your suggestion works well in my project

[isc30]

@chordmemory this works wonders, maybe rollup should have that inside the codebase just in case a plugin keeps handles open after outputting

[lukastaegert]

That is what I tried, but it breaks a lot of stuff for other workflows. The only good solution would be to figure out what exactly is keeping the process open, but we had no success so far as it does not happen very reliably.

[chordmemory]

@lukastaegert I have a pretty complicated config that can reliably reproduce (1/2 times) - I can't share it, but do you have any advice or ideas for how to debug the leak?

[lukastaegert]

Not really. To my knowledge, there are mostly two things that can prevent a process from completing:

• asynchronous tasks that are still running
• some kind of global event listeners

Maybe using the Chrome debugger attached to the Node process might give a clue what might still be running or scheduled. I had no luck reproducing the issue in a situation where I had a debugger attached so far.

[tjenkinson]

Have you tried https://github.com/mafintosh/why-is-node-running ?

[woutervanvliet]

@lukastaegert I've had success using the same workaround from the revert pr.

For anyone struggling with this, but needing to intake new rollup versions, try adding this as the last plugin in your plugin array in rollup.config.js :

{
    closeBundle() {
        if (!process.env.ROLLUP_WATCH) {
          setTimeout(() => process.exit(0));
        }
    },
    name: 'force-close'
}

Thanks! I've implemented a solution based on your suggestion, and I feel rather confident this will work. Had to slightly modify it though, as my rollup config exports an array of configurations; and I want them all to complete. For anybody in a similar situation; here's my solution:

let runningBundles = 0

/**
 * @param {string} name
 * @param {number} maxWaitTime Maximum number of seconds to wait for Rollup to exit before force-exiting
 * @returns {{closeBundle(): void, buildStart(): void, name: string}}
 */
export const rollupForceExit = (name, maxWaitTime = 60) => {
    return {
        /** @this {import('rollup').PluginContext} */
        buildStart() {
            if (this.meta.watchMode) {
                return
            }

            runningBundles++
            this.info(`${name}: Starting build, ${runningBundles} build(s) running`)
        },
        /** @this {import('rollup').PluginContext} */
        closeBundle() {
            if (this.meta.watchMode) {
                return
            }

            runningBundles--
            const timeout = setTimeout(() => {
                if (runningBundles === 0) {
                    this.info(
                        `${name}: Rollup is now done, but did not exit before ${maxWaitTime} seconds, force exiting...`
                    )
                    process.exit(0)
                } else {
                    this.info(
                        `${name}: Rollup is still working on another build process, waiting for ${runningBundles} running bundle(s) before force exit`
                    )
                }
            }, maxWaitTime * 1000)
            // Allow the NodeJS process to finish without waiting for the timeout, using it only as a fallback for
            // otherwise hanging Rollup processes
            timeout.unref()
        },
        name: 'force-close',
    }
}

This also tries to account for any other plugins that might want to do some amount of work in closeBundle

[github-actions]

This issue has been resolved via #5195 as part of rollup@4.3.0. You can test it via npm install rollup.