Why do postinstall scripts exit with code 0 on failure?

[mhassan1]

Versions

• NodeJS: 14.15.1
• mongodb-memory-server-*: 6.9.3
• mongodb: 4.4.1
• mongoose: 5.11.15
• system: MacOS

package: mongodb-memory-server

What is your question?

In the postinstall script in mongodb-memory-server, there are a few failure conditions that result in an exit code of 0, for example:

• https://github.com/nodkz/mongodb-memory-server/blob/master/packages/mongodb-memory-server/postinstall.js#L23
• https://github.com/nodkz/mongodb-memory-server/blob/master/packages/mongodb-memory-server/postinstall.js#L54
• https://github.com/nodkz/mongodb-memory-server/blob/master/packages/mongodb-memory-server/postinstall.js#L57

I see related discussion here: #131

IMO, the postinstall should not exit with code 0 when the script fails to do what the consumer expects. Presumably, consumers are using the mongodb-memory-server package because they want the postinstall step to happen; if they didn't care about that, then they would use mongodb-memory-server-core, instead. If the postinstall fails, they should be notified with a non-zero exit code; if they don't like that behavior, they can opt for the core package, or we can offer them another way to opt out of that behavior.

What was the reasoning behind exiting with code 0 for failure cases?

[hasezoey]

as an note, you were looking at outdated files (but the point still stands):

• https://github.com/nodkz/mongodb-memory-server/blob/beta/packages/mongodb-memory-server-global/postinstall.js
• https://github.com/nodkz/mongodb-memory-server/blob/beta/packages/mongodb-memory-server-core/src/util/postinstallHelper.ts

this is currently to not block the install of the packages (might be counter intuitive)

@nodkz do you think we should actually fail in the postinstall? (aside from "skip" & "systembinary")

[nodkz]

Motivation:

• supposemongodb-memory-server block packages installation by default – if some package blocks installation I remove it from my dependencies. And most developers will do the same. Also, they do not run tests often, why they should be injured and their work halted by some package? And mongodb binary upstream sometimes has problems with DNS.
• if postinstall fails and does not download binaries – then binaries will be downloaded on test start. They are checked every time before the test starts and download binaries if they are missing.

We can add a new option for package.json or env variable e.g MONGOMS_FAIL_ON_POSTINSTALL or something similar. And in this case on postinstall exit with non-zero code. So you will be able to explicitly enable this option with tough behavior 😉

@mhassan1 @hasezoey how do you think this option/env can be named? Is MONGOMS_FAIL_ON_POSTINSTALL good enough?

[mhassan1]

Personally, I think the default behavior should be to fail, with an option like MONGOMS_IGNORE_POSTINSTALL_ERRORS if you want to ignore it temporarily, but I won't argue 😉.

I think something like MONGOMS_FAIL_ON_POSTINSTALL_ERRORS is more explicit.

[hasezoey]

isnt MONGOMS_IGNORE_POSTINSTALL_ERRORS basically MONGOMS_DISABLE_POSTINSTALL?

and when implementing MONGOMS_IGNORE_POSTINSTALL_ERRORS or MONGOMS_FAIL_ON_POSTINSTALL_ERRORS, what should be do about MONGOMS_DISABLE_POSTINSTALL, keep it or remove it?

[mhassan1]

Good point. There's not much of a difference between MONGOMS_IGNORE_POSTINSTALL_ERRORS and MONGOMS_DISABLE_POSTINSTALL.

[hasezoey]

actually, when implementing a way to not fail with code 0, we could maybe add an test that creates an temporary directory and an basic package.json and try to install everything (with local linking install)