Add build error handling

[trusktr]

Summary

Add error handling to build processes so they don't silently fail.

What kind of change does this PR introduce? (check at least one)

• Bugfix?
• Feature
• Code style update
• Refactor
• Docs
• Build-related changes
• Other, please describe:

If changing the UI of default theme, please provide the before/after screenshot:

Does this PR introduce a breaking change? (check one)

• Yes
• No

If yes, please describe the impact and migration path for existing applications:

The PR fulfills these requirements:

• When resolving a specific issue, it's referenced in the PR's title (e.g. fix #xxx[,#xxx], where "xxx" is the issue number)

You have tested in the following browsers: (Providing a detailed version will be better.)

• Chrome
• Firefox
• Safari
• Edge
• IE

If adding a new feature, the PR's description includes:

• A convincing reason for adding this feature
• Related documents have been updated
• Related tests have been updated

To avoid wasting your time, it's best to open a feature request issue first and wait for approval before working on it.

Other information:

---

• DO NOT include files inside lib directory.

[vercel]

This pull request is being automatically deployed with Vercel (learn more).
To see the status of your deployment, click below or on the icon next to each commit.

🔍 Inspect: https://vercel.com/docsify-core/docsify-preview/hsx5hz7n8
✅ Preview: https://docsify-preview-git-add-build-error-handling.docsify-core.now.sh

[trusktr]

Now the error I'm getting, which I don't understand, is

❯ node --trace-warnings ./node_modules/.bin/npm run build

> [email protected] build /home/trusktr/src/lume+umbrella/packages/docsifyjs+docsify
> rimraf lib themes && run-s build:js build:css build:css:min build:ssr build:cover


> [email protected] build:js /home/trusktr/src/lume+umbrella/packages/docsifyjs+docsify
> cross-env NODE_ENV=production node build/build.js

lib/plugins/ga.min.js
lib/plugins/ga.js
lib/plugins/matomo.min.js
lib/plugins/matomo.js
lib/plugins/emoji.min.js
lib/plugins/emoji.js
lib/plugins/external-script.js
lib/plugins/external-script.min.js
lib/plugins/disqus.js
lib/plugins/disqus.min.js
lib/plugins/gitalk.js
lib/plugins/gitalk.min.js
lib/plugins/zoom-image.min.js
lib/plugins/zoom-image.js
lib/plugins/search.js
lib/plugins/search.min.js
lib/plugins/front-matter.js
lib/plugins/front-matter.min.js
lib/docsify.js
Error: You must supply "output.name" for IIFE bundles.
    at error (/home/trusktr/src/lume+umbrella/packages/docsifyjs+docsify/node_modules/rollup/dist/rollup.js:10162:30)
    at iife (/home/trusktr/src/lume+umbrella/packages/docsifyjs+docsify/node_modules/rollup/dist/rollup.js:10408:9)
    at Chunk$1.render (/home/trusktr/src/lume+umbrella/packages/docsifyjs+docsify/node_modules/rollup/dist/rollup.js:15561:29)
    at /home/trusktr/src/lume+umbrella/packages/docsifyjs+docsify/node_modules/rollup/dist/rollup.js:18025:38
    at Array.map (<anonymous>)
    at /home/trusktr/src/lume+umbrella/packages/docsifyjs+docsify/node_modules/rollup/dist/rollup.js:18023:46
    at Generator.next (<anonymous>)
    at fulfilled (/home/trusktr/src/lume+umbrella/packages/docsifyjs+docsify/node_modules/rollup/dist/rollup.js:40:28)
    at runMicrotasks (<anonymous>)
    at processTicksAndRejections (internal/process/task_queues.js:97:5) {

It fails on building docsify.js.

[trusktr]

But why would this fail now and not before?

[anikethsaha]

But why would this fail now and not before?

not sure, I think rollup is async by default ?

[trusktr]

The issue is basically

• output iife without name rollup/rollup-plugin-commonjs#274
• Remove the need to provide an output name for IIFE bundles rollup/rollup#3181

It's late though, so I will think about this tomorrow. I think that we'll just export whatever the globals we need from the index.js file, and set the output.name. This will replace the call to initGlobalAPI, plus make the code more useful.

Avoiding globals is better, but that's for another topic.

[trusktr]

rollup is async by default

Yep, it is. In earlier versions of Node (f.e. Node 10) unhandled Promise rejections are silent errors that don't terminate the program. So we have to add the explicit error handling to ensure that the build fails when there's an error. In newer versions of Node, any unhandled Promise rejections automatically end the program with non-zero exit.