Update dependencies (#20)

- @actions/core
- glob
- screeps-api

Reviewed-on: #20
Co-authored-by: Philipp Horstenkamp <philipp@horstenkamp.de>
Co-committed-by: Philipp Horstenkamp <philipp@horstenkamp.de>

node_modules/signal-exit/README.md

@@ -1,39 +1,74 @@
 # signal-exit
 
-[![Build Status](https://travis-ci.org/tapjs/signal-exit.png)](https://travis-ci.org/tapjs/signal-exit)
-[![Coverage](https://coveralls.io/repos/tapjs/signal-exit/badge.svg?branch=master)](https://coveralls.io/r/tapjs/signal-exit?branch=master)
-[![NPM version](https://img.shields.io/npm/v/signal-exit.svg)](https://www.npmjs.com/package/signal-exit)
-[![Standard Version](https://img.shields.io/badge/release-standard%20version-brightgreen.svg)](https://github.com/conventional-changelog/standard-version)
-
 When you want to fire an event no matter how a process exits:
 
-* reaching the end of execution.
-* explicitly having `process.exit(code)` called.
-* having `process.kill(pid, sig)` called.
-* receiving a fatal signal from outside the process
+- reaching the end of execution.
+- explicitly having `process.exit(code)` called.
+- having `process.kill(pid, sig)` called.
+- receiving a fatal signal from outside the process
 
 Use `signal-exit`.
 
 ```js
-var onExit = require('signal-exit')
+// Hybrid module, either works
+import { onExit } from 'signal-exit'
+// or:
+// const { onExit } = require('signal-exit')
 
-onExit(function (code, signal) {
-  console.log('process exited!')
+onExit((code, signal) => {
+  console.log('process exited!', code, signal)
 })
 ```
 
 ## API
 
-`var remove = onExit(function (code, signal) {}, options)`
+`remove = onExit((code, signal) => {}, options)`
 
-The return value of the function is a function that will remove the
-handler.
+The return value of the function is a function that will remove
+the handler.
 
-Note that the function *only* fires for signals if the signal would
-cause the process to exit.  That is, there are no other listeners, and
-it is a fatal signal.
+Note that the function _only_ fires for signals if the signal
+would cause the process to exit. That is, there are no other
+listeners, and it is a fatal signal.
 
-## Options
+If the global `process` object is not suitable for this purpose
+(ie, it's unset, or doesn't have an `emit` method, etc.) then the
+`onExit` function is a no-op that returns a no-op `remove` method.
 
-* `alwaysLast`: Run this handler after any other signal or exit
-  handlers.  This causes `process.emit` to be monkeypatched.
+### Options
+
+- `alwaysLast`: Run this handler after any other signal or exit
+  handlers. This causes `process.emit` to be monkeypatched.
+
+### Capturing Signal Exits
+
+If the handler returns an exact boolean `true`, and the exit is a
+due to signal, then the signal will be considered handled, and
+will _not_ trigger a synthetic `process.kill(process.pid,
+signal)` after firing the `onExit` handlers.
+
+In this case, it your responsibility as the caller to exit with a
+signal (for example, by calling `process.kill()`) if you wish to
+preserve the same exit status that would otherwise have occurred.
+If you do not, then the process will likely exit gracefully with
+status 0 at some point, assuming that no other terminating signal
+or other exit trigger occurs.
+
+Prior to calling handlers, the `onExit` machinery is unloaded, so
+any subsequent exits or signals will not be handled, even if the
+signal is captured and the exit is thus prevented.
+
+Note that numeric code exits may indicate that the process is
+already committed to exiting, for example due to a fatal
+exception or unhandled promise rejection, and so there is no way to
+prevent it safely.
+
+### Browser Fallback
+
+The `'signal-exit/browser'` module is the same fallback shim that
+just doesn't do anything, but presents the same function
+interface.
+
+Patches welcome to add something that hooks onto
+`window.onbeforeunload` or similar, but it might just not be a
+thing that makes sense there.