Quiet down or silence non-errors in npm install

[wesbos]

npm install output scares people

Summary

npm install shows too much low level information which is unhelpful to most developers.

Motivation

There is no way to tell if a npm install has worked or not. Many of my students are confused at the output as it looks like something has gone wrong when everything runs just fine.

Detailed Explanation

Just npm install something and look at the output. This was from 100% success:

Rationale and Alternatives

Some people have suggested --silent as a good solution, but that will hide good errors as well, no?

Implementation

If everything worked, then don't show a bunch of scary things on the screen.

Prior Art

yarn, pnpm

[darcyclarke]

@wesbos Just as a quick information gathering, can you show the output of both pnpm & yarn against this same project?

[wesbos]

Seems like Yarn has even worse output in this case - same but not highlighted. pnpm is similar so apologies there.

I think a lot of this has to do with native modules puking on the screen - is there something that can be done to test if it worked or not and suppress these?

[darcyclarke]

@wesbos you might try changing the loglevel; There's some options for you & shorthands here: https://docs.npmjs.com/misc/config#shorthands-and-other-cli-nicities (one of which includes --silent but that, as you noted/guessed, would hide errors)

Try npm install --quiet OR shorthand npm i -q (may/may not help in this case)

[wesbos]

Yeah, the problem isn't that I don't know how to fix it, it's that I get hundreds of emails/tweets/dms/slacks from people who think it broke on install when in reality I have to say "No, no 400 lines of errors, warnings is completely normal".

Would some sort of better default be good here?

[darcyclarke]

@wesbos totally. Might want to update that "Prior Art" section though...

[wesbos]

:) Also once all the issues with native modules go away, this is still the output:

Everything but the security is unhelpful to me.

Even with --silent, I still get some stuff:

It should also say "It worked!" or "successful install" once it's all done, no?

[darcyclarke]

@wesbos appreciate these screens/added context. Definitely helps round things out. I do like/want sane defaults so I think that we'll focus on that as we go forward.

Hoping we can bring this up/prioritize early in the New Year at our first Open RFC call in 2020; Would love to have you hop on, if you can make it, to discuss this & we'll get any work associated prioritized accordingly.

[isaacs]

We are already planning on running install scripts in a background process and only printing the results if the installation meaningfully fails. (Ie, exits non-zero for a non-optional installation.)

We held back on doing that because it would make the current fundraising approaches impossible, which was a bit more opinionated than we wanted to get at this time. With the arrival of npm fund, I think we're unblocked and ready to move forward on it, though.

[wesbos]

Great - looking forward to that

[isaacs]

@rbeer It's not a legit install error, though, because it's an optional dependency. It's probably fine to just show a warning that an optional dep was omitted. And, since we do installations in parallel, it gets pretty gnarly if you have multiple builds going on simultaneously sharing the same stdio. We plan to push all lifecycle scripts to a stdio-piped process, and print stdout/stderr only if it's a failure that we care about (ie, non-zero exit code for non-optional dependency). This will also allow us to prevent interleaved output.

[wesleytodd]

Is there an rfc for this background behavior @isaacs? This might break more than just the fund use case. Not that I think it is bad, I would just like to read and maybe give feedback on it.

[isaacs]

@wesleytodd Hm, I don't see one. It looks like it was added to the roadmap before I switched back to a technical role with the CLI, could've been before the RFC process even started. We can write one up, though.

[wesbos]

npm install output scares people

Summary

npm install shows too much low level information which is unhelpful to most developers.

Motivation

There is no way to tell if a npm install has worked or not. Many of my students are confused at the output as it looks like something has gone wrong when everything runs just fine.

Detailed Explanation

Just npm install something and look at the output. This was from 100% success:

Rationale and Alternatives

Some people have suggested --silent as a good solution, but that will hide good errors as well, no?

Implementation

If everything worked, then don't show a bunch of scary things on the screen.

Prior Art

yarn, pnpm

[darcyclarke]

@wesbos Just as a quick information gathering, can you show the output of both pnpm & yarn against this same project?

[wesbos]

Seems like Yarn has even worse output in this case - same but not highlighted. pnpm is similar so apologies there.

I think a lot of this has to do with native modules puking on the screen - is there something that can be done to test if it worked or not and suppress these?

[darcyclarke]

@wesbos you might try changing the loglevel; There's some options for you & shorthands here: https://docs.npmjs.com/misc/config#shorthands-and-other-cli-nicities (one of which includes --silent but that, as you noted/guessed, would hide errors)

Try npm install --quiet OR shorthand npm i -q (may/may not help in this case)

[wesbos]

Yeah, the problem isn't that I don't know how to fix it, it's that I get hundreds of emails/tweets/dms/slacks from people who think it broke on install when in reality I have to say "No, no 400 lines of errors, warnings is completely normal".

Would some sort of better default be good here?

[darcyclarke]

@wesbos totally. Might want to update that "Prior Art" section though...

[wesbos]

:) Also once all the issues with native modules go away, this is still the output:

Everything but the security is unhelpful to me.

Even with --silent, I still get some stuff:

It should also say "It worked!" or "successful install" once it's all done, no?

[darcyclarke]

@wesbos appreciate these screens/added context. Definitely helps round things out. I do like/want sane defaults so I think that we'll focus on that as we go forward.

Hoping we can bring this up/prioritize early in the New Year at our first Open RFC call in 2020; Would love to have you hop on, if you can make it, to discuss this & we'll get any work associated prioritized accordingly.

[isaacs]

We are already planning on running install scripts in a background process and only printing the results if the installation meaningfully fails. (Ie, exits non-zero for a non-optional installation.)

We held back on doing that because it would make the current fundraising approaches impossible, which was a bit more opinionated than we wanted to get at this time. With the arrival of npm fund, I think we're unblocked and ready to move forward on it, though.

[wesbos]

Great - looking forward to that

[isaacs]

@rbeer It's not a legit install error, though, because it's an optional dependency. It's probably fine to just show a warning that an optional dep was omitted. And, since we do installations in parallel, it gets pretty gnarly if you have multiple builds going on simultaneously sharing the same stdio. We plan to push all lifecycle scripts to a stdio-piped process, and print stdout/stderr only if it's a failure that we care about (ie, non-zero exit code for non-optional dependency). This will also allow us to prevent interleaved output.

[wesleytodd]

Is there an rfc for this background behavior @isaacs? This might break more than just the fund use case. Not that I think it is bad, I would just like to read and maybe give feedback on it.

[isaacs]

@wesleytodd Hm, I don't see one. It looks like it was added to the roadmap before I switched back to a technical role with the CLI, could've been before the RFC process even started. We can write one up, though.

[wesbos]

npm install output scares people

Summary

npm install shows too much low level information which is unhelpful to most developers.

Motivation

There is no way to tell if a npm install has worked or not. Many of my students are confused at the output as it looks like something has gone wrong when everything runs just fine.

Detailed Explanation

Just npm install something and look at the output. This was from 100% success:

Rationale and Alternatives

Some people have suggested --silent as a good solution, but that will hide good errors as well, no?

Implementation

If everything worked, then don't show a bunch of scary things on the screen.

Prior Art

yarn, pnpm

[darcyclarke]

@wesbos Just as a quick information gathering, can you show the output of both pnpm & yarn against this same project?

[wesbos]

Seems like Yarn has even worse output in this case - same but not highlighted. pnpm is similar so apologies there.

I think a lot of this has to do with native modules puking on the screen - is there something that can be done to test if it worked or not and suppress these?

[darcyclarke]

@wesbos you might try changing the loglevel; There's some options for you & shorthands here: https://docs.npmjs.com/misc/config#shorthands-and-other-cli-nicities (one of which includes --silent but that, as you noted/guessed, would hide errors)

Try npm install --quiet OR shorthand npm i -q (may/may not help in this case)

[wesbos]

Yeah, the problem isn't that I don't know how to fix it, it's that I get hundreds of emails/tweets/dms/slacks from people who think it broke on install when in reality I have to say "No, no 400 lines of errors, warnings is completely normal".

Would some sort of better default be good here?

[darcyclarke]

@wesbos totally. Might want to update that "Prior Art" section though...

[wesbos]

:) Also once all the issues with native modules go away, this is still the output:

Everything but the security is unhelpful to me.

Even with --silent, I still get some stuff:

It should also say "It worked!" or "successful install" once it's all done, no?

[darcyclarke]

@wesbos appreciate these screens/added context. Definitely helps round things out. I do like/want sane defaults so I think that we'll focus on that as we go forward.

Hoping we can bring this up/prioritize early in the New Year at our first Open RFC call in 2020; Would love to have you hop on, if you can make it, to discuss this & we'll get any work associated prioritized accordingly.

[isaacs]

We are already planning on running install scripts in a background process and only printing the results if the installation meaningfully fails. (Ie, exits non-zero for a non-optional installation.)

We held back on doing that because it would make the current fundraising approaches impossible, which was a bit more opinionated than we wanted to get at this time. With the arrival of npm fund, I think we're unblocked and ready to move forward on it, though.

[wesbos]

Great - looking forward to that

[isaacs]

@rbeer It's not a legit install error, though, because it's an optional dependency. It's probably fine to just show a warning that an optional dep was omitted. And, since we do installations in parallel, it gets pretty gnarly if you have multiple builds going on simultaneously sharing the same stdio. We plan to push all lifecycle scripts to a stdio-piped process, and print stdout/stderr only if it's a failure that we care about (ie, non-zero exit code for non-optional dependency). This will also allow us to prevent interleaved output.

[wesleytodd]

Is there an rfc for this background behavior @isaacs? This might break more than just the fund use case. Not that I think it is bad, I would just like to read and maybe give feedback on it.

[isaacs]

@wesleytodd Hm, I don't see one. It looks like it was added to the roadmap before I switched back to a technical role with the CLI, could've been before the RFC process even started. We can write one up, though.

[wesbos]

npm install output scares people

Summary

npm install shows too much low level information which is unhelpful to most developers.

Motivation

There is no way to tell if a npm install has worked or not. Many of my students are confused at the output as it looks like something has gone wrong when everything runs just fine.

Detailed Explanation

Just npm install something and look at the output. This was from 100% success:

Rationale and Alternatives

Some people have suggested --silent as a good solution, but that will hide good errors as well, no?

Implementation

If everything worked, then don't show a bunch of scary things on the screen.

Prior Art

yarn, pnpm

[darcyclarke]

@wesbos Just as a quick information gathering, can you show the output of both pnpm & yarn against this same project?

[wesbos]

Seems like Yarn has even worse output in this case - same but not highlighted. pnpm is similar so apologies there.

I think a lot of this has to do with native modules puking on the screen - is there something that can be done to test if it worked or not and suppress these?

[darcyclarke]

@wesbos you might try changing the loglevel; There's some options for you & shorthands here: https://docs.npmjs.com/misc/config#shorthands-and-other-cli-nicities (one of which includes --silent but that, as you noted/guessed, would hide errors)

Try npm install --quiet OR shorthand npm i -q (may/may not help in this case)

[wesbos]

Yeah, the problem isn't that I don't know how to fix it, it's that I get hundreds of emails/tweets/dms/slacks from people who think it broke on install when in reality I have to say "No, no 400 lines of errors, warnings is completely normal".

Would some sort of better default be good here?

[darcyclarke]

@wesbos totally. Might want to update that "Prior Art" section though...

[wesbos]

:) Also once all the issues with native modules go away, this is still the output:

Everything but the security is unhelpful to me.

Even with --silent, I still get some stuff:

It should also say "It worked!" or "successful install" once it's all done, no?

[darcyclarke]

@wesbos appreciate these screens/added context. Definitely helps round things out. I do like/want sane defaults so I think that we'll focus on that as we go forward.

Hoping we can bring this up/prioritize early in the New Year at our first Open RFC call in 2020; Would love to have you hop on, if you can make it, to discuss this & we'll get any work associated prioritized accordingly.

[isaacs]

We are already planning on running install scripts in a background process and only printing the results if the installation meaningfully fails. (Ie, exits non-zero for a non-optional installation.)

We held back on doing that because it would make the current fundraising approaches impossible, which was a bit more opinionated than we wanted to get at this time. With the arrival of npm fund, I think we're unblocked and ready to move forward on it, though.

[wesbos]

Great - looking forward to that

[isaacs]

@rbeer It's not a legit install error, though, because it's an optional dependency. It's probably fine to just show a warning that an optional dep was omitted. And, since we do installations in parallel, it gets pretty gnarly if you have multiple builds going on simultaneously sharing the same stdio. We plan to push all lifecycle scripts to a stdio-piped process, and print stdout/stderr only if it's a failure that we care about (ie, non-zero exit code for non-optional dependency). This will also allow us to prevent interleaved output.

[wesleytodd]

Is there an rfc for this background behavior @isaacs? This might break more than just the fund use case. Not that I think it is bad, I would just like to read and maybe give feedback on it.

[isaacs]

@wesleytodd Hm, I don't see one. It looks like it was added to the roadmap before I switched back to a technical role with the CLI, could've been before the RFC process even started. We can write one up, though.

[wesbos]

npm install output scares people

Summary

npm install shows too much low level information which is unhelpful to most developers.

Motivation

There is no way to tell if a npm install has worked or not. Many of my students are confused at the output as it looks like something has gone wrong when everything runs just fine.

Detailed Explanation

Just npm install something and look at the output. This was from 100% success:

Rationale and Alternatives

Some people have suggested --silent as a good solution, but that will hide good errors as well, no?

Implementation

If everything worked, then don't show a bunch of scary things on the screen.

Prior Art

yarn, pnpm

[darcyclarke]

@wesbos Just as a quick information gathering, can you show the output of both pnpm & yarn against this same project?

[wesbos]

Seems like Yarn has even worse output in this case - same but not highlighted. pnpm is similar so apologies there.

I think a lot of this has to do with native modules puking on the screen - is there something that can be done to test if it worked or not and suppress these?

[darcyclarke]

@wesbos you might try changing the loglevel; There's some options for you & shorthands here: https://docs.npmjs.com/misc/config#shorthands-and-other-cli-nicities (one of which includes --silent but that, as you noted/guessed, would hide errors)

Try npm install --quiet OR shorthand npm i -q (may/may not help in this case)

[wesbos]

Yeah, the problem isn't that I don't know how to fix it, it's that I get hundreds of emails/tweets/dms/slacks from people who think it broke on install when in reality I have to say "No, no 400 lines of errors, warnings is completely normal".

Would some sort of better default be good here?

[darcyclarke]

@wesbos totally. Might want to update that "Prior Art" section though...

[wesbos]

:) Also once all the issues with native modules go away, this is still the output:

Everything but the security is unhelpful to me.

Even with --silent, I still get some stuff:

It should also say "It worked!" or "successful install" once it's all done, no?

[darcyclarke]

@wesbos appreciate these screens/added context. Definitely helps round things out. I do like/want sane defaults so I think that we'll focus on that as we go forward.

Hoping we can bring this up/prioritize early in the New Year at our first Open RFC call in 2020; Would love to have you hop on, if you can make it, to discuss this & we'll get any work associated prioritized accordingly.

[isaacs]

We are already planning on running install scripts in a background process and only printing the results if the installation meaningfully fails. (Ie, exits non-zero for a non-optional installation.)

We held back on doing that because it would make the current fundraising approaches impossible, which was a bit more opinionated than we wanted to get at this time. With the arrival of npm fund, I think we're unblocked and ready to move forward on it, though.

[wesbos]

Great - looking forward to that

[isaacs]

@rbeer It's not a legit install error, though, because it's an optional dependency. It's probably fine to just show a warning that an optional dep was omitted. And, since we do installations in parallel, it gets pretty gnarly if you have multiple builds going on simultaneously sharing the same stdio. We plan to push all lifecycle scripts to a stdio-piped process, and print stdout/stderr only if it's a failure that we care about (ie, non-zero exit code for non-optional dependency). This will also allow us to prevent interleaved output.

[wesleytodd]

Is there an rfc for this background behavior @isaacs? This might break more than just the fund use case. Not that I think it is bad, I would just like to read and maybe give feedback on it.

[isaacs]

@wesleytodd Hm, I don't see one. It looks like it was added to the roadmap before I switched back to a technical role with the CLI, could've been before the RFC process even started. We can write one up, though.

[wesbos]

npm install output scares people

Summary

npm install shows too much low level information which is unhelpful to most developers.

Motivation

There is no way to tell if a npm install has worked or not. Many of my students are confused at the output as it looks like something has gone wrong when everything runs just fine.

Detailed Explanation

Just npm install something and look at the output. This was from 100% success:

Rationale and Alternatives

Some people have suggested --silent as a good solution, but that will hide good errors as well, no?

Implementation

If everything worked, then don't show a bunch of scary things on the screen.

Prior Art

yarn, pnpm

[darcyclarke]

@wesbos Just as a quick information gathering, can you show the output of both pnpm & yarn against this same project?

[wesbos]

Seems like Yarn has even worse output in this case - same but not highlighted. pnpm is similar so apologies there.

I think a lot of this has to do with native modules puking on the screen - is there something that can be done to test if it worked or not and suppress these?

[darcyclarke]

@wesbos you might try changing the loglevel; There's some options for you & shorthands here: https://docs.npmjs.com/misc/config#shorthands-and-other-cli-nicities (one of which includes --silent but that, as you noted/guessed, would hide errors)

Try npm install --quiet OR shorthand npm i -q (may/may not help in this case)

[wesbos]

Yeah, the problem isn't that I don't know how to fix it, it's that I get hundreds of emails/tweets/dms/slacks from people who think it broke on install when in reality I have to say "No, no 400 lines of errors, warnings is completely normal".

Would some sort of better default be good here?

[darcyclarke]

@wesbos totally. Might want to update that "Prior Art" section though...

[wesbos]

:) Also once all the issues with native modules go away, this is still the output:

Everything but the security is unhelpful to me.

Even with --silent, I still get some stuff:

It should also say "It worked!" or "successful install" once it's all done, no?

[darcyclarke]

@wesbos appreciate these screens/added context. Definitely helps round things out. I do like/want sane defaults so I think that we'll focus on that as we go forward.

Hoping we can bring this up/prioritize early in the New Year at our first Open RFC call in 2020; Would love to have you hop on, if you can make it, to discuss this & we'll get any work associated prioritized accordingly.

[isaacs]

We are already planning on running install scripts in a background process and only printing the results if the installation meaningfully fails. (Ie, exits non-zero for a non-optional installation.)

We held back on doing that because it would make the current fundraising approaches impossible, which was a bit more opinionated than we wanted to get at this time. With the arrival of npm fund, I think we're unblocked and ready to move forward on it, though.

[wesbos]

Great - looking forward to that

[isaacs]

@rbeer It's not a legit install error, though, because it's an optional dependency. It's probably fine to just show a warning that an optional dep was omitted. And, since we do installations in parallel, it gets pretty gnarly if you have multiple builds going on simultaneously sharing the same stdio. We plan to push all lifecycle scripts to a stdio-piped process, and print stdout/stderr only if it's a failure that we care about (ie, non-zero exit code for non-optional dependency). This will also allow us to prevent interleaved output.

[wesleytodd]

Is there an rfc for this background behavior @isaacs? This might break more than just the fund use case. Not that I think it is bad, I would just like to read and maybe give feedback on it.

[isaacs]

@wesleytodd Hm, I don't see one. It looks like it was added to the roadmap before I switched back to a technical role with the CLI, could've been before the RFC process even started. We can write one up, though.

[wesbos]

npm install output scares people

Summary

npm install shows too much low level information which is unhelpful to most developers.

Motivation

There is no way to tell if a npm install has worked or not. Many of my students are confused at the output as it looks like something has gone wrong when everything runs just fine.

Detailed Explanation

Just npm install something and look at the output. This was from 100% success:

Rationale and Alternatives

Some people have suggested --silent as a good solution, but that will hide good errors as well, no?

Implementation

If everything worked, then don't show a bunch of scary things on the screen.

Prior Art

yarn, pnpm

[darcyclarke]

@wesbos Just as a quick information gathering, can you show the output of both pnpm & yarn against this same project?

[wesbos]

Seems like Yarn has even worse output in this case - same but not highlighted. pnpm is similar so apologies there.

I think a lot of this has to do with native modules puking on the screen - is there something that can be done to test if it worked or not and suppress these?

[darcyclarke]

@wesbos you might try changing the loglevel; There's some options for you & shorthands here: https://docs.npmjs.com/misc/config#shorthands-and-other-cli-nicities (one of which includes --silent but that, as you noted/guessed, would hide errors)

Try npm install --quiet OR shorthand npm i -q (may/may not help in this case)

[wesbos]

Yeah, the problem isn't that I don't know how to fix it, it's that I get hundreds of emails/tweets/dms/slacks from people who think it broke on install when in reality I have to say "No, no 400 lines of errors, warnings is completely normal".

Would some sort of better default be good here?

[darcyclarke]

@wesbos totally. Might want to update that "Prior Art" section though...

[wesbos]

:) Also once all the issues with native modules go away, this is still the output:

Everything but the security is unhelpful to me.

Even with --silent, I still get some stuff:

It should also say "It worked!" or "successful install" once it's all done, no?

[darcyclarke]

@wesbos appreciate these screens/added context. Definitely helps round things out. I do like/want sane defaults so I think that we'll focus on that as we go forward.

Hoping we can bring this up/prioritize early in the New Year at our first Open RFC call in 2020; Would love to have you hop on, if you can make it, to discuss this & we'll get any work associated prioritized accordingly.

[isaacs]

We are already planning on running install scripts in a background process and only printing the results if the installation meaningfully fails. (Ie, exits non-zero for a non-optional installation.)

We held back on doing that because it would make the current fundraising approaches impossible, which was a bit more opinionated than we wanted to get at this time. With the arrival of npm fund, I think we're unblocked and ready to move forward on it, though.

[wesbos]

Great - looking forward to that

[isaacs]

@rbeer It's not a legit install error, though, because it's an optional dependency. It's probably fine to just show a warning that an optional dep was omitted. And, since we do installations in parallel, it gets pretty gnarly if you have multiple builds going on simultaneously sharing the same stdio. We plan to push all lifecycle scripts to a stdio-piped process, and print stdout/stderr only if it's a failure that we care about (ie, non-zero exit code for non-optional dependency). This will also allow us to prevent interleaved output.

[wesleytodd]

Is there an rfc for this background behavior @isaacs? This might break more than just the fund use case. Not that I think it is bad, I would just like to read and maybe give feedback on it.

[isaacs]

@wesleytodd Hm, I don't see one. It looks like it was added to the roadmap before I switched back to a technical role with the CLI, could've been before the RFC process even started. We can write one up, though.

[wesbos]

npm install output scares people

Summary

npm install shows too much low level information which is unhelpful to most developers.

Motivation

There is no way to tell if a npm install has worked or not. Many of my students are confused at the output as it looks like something has gone wrong when everything runs just fine.

Detailed Explanation

Just npm install something and look at the output. This was from 100% success:

Rationale and Alternatives

Some people have suggested --silent as a good solution, but that will hide good errors as well, no?

Implementation

If everything worked, then don't show a bunch of scary things on the screen.

Prior Art

yarn, pnpm

[darcyclarke]

@wesbos Just as a quick information gathering, can you show the output of both pnpm & yarn against this same project?

[wesbos]

Seems like Yarn has even worse output in this case - same but not highlighted. pnpm is similar so apologies there.

I think a lot of this has to do with native modules puking on the screen - is there something that can be done to test if it worked or not and suppress these?

[darcyclarke]

@wesbos you might try changing the loglevel; There's some options for you & shorthands here: https://docs.npmjs.com/misc/config#shorthands-and-other-cli-nicities (one of which includes --silent but that, as you noted/guessed, would hide errors)

Try npm install --quiet OR shorthand npm i -q (may/may not help in this case)

[wesbos]

Yeah, the problem isn't that I don't know how to fix it, it's that I get hundreds of emails/tweets/dms/slacks from people who think it broke on install when in reality I have to say "No, no 400 lines of errors, warnings is completely normal".

Would some sort of better default be good here?

[darcyclarke]

@wesbos totally. Might want to update that "Prior Art" section though...

[wesbos]

:) Also once all the issues with native modules go away, this is still the output:

Everything but the security is unhelpful to me.

Even with --silent, I still get some stuff:

It should also say "It worked!" or "successful install" once it's all done, no?

[darcyclarke]

@wesbos appreciate these screens/added context. Definitely helps round things out. I do like/want sane defaults so I think that we'll focus on that as we go forward.

Hoping we can bring this up/prioritize early in the New Year at our first Open RFC call in 2020; Would love to have you hop on, if you can make it, to discuss this & we'll get any work associated prioritized accordingly.

[isaacs]

We are already planning on running install scripts in a background process and only printing the results if the installation meaningfully fails. (Ie, exits non-zero for a non-optional installation.)

We held back on doing that because it would make the current fundraising approaches impossible, which was a bit more opinionated than we wanted to get at this time. With the arrival of npm fund, I think we're unblocked and ready to move forward on it, though.

[wesbos]

Great - looking forward to that

[isaacs]

@rbeer It's not a legit install error, though, because it's an optional dependency. It's probably fine to just show a warning that an optional dep was omitted. And, since we do installations in parallel, it gets pretty gnarly if you have multiple builds going on simultaneously sharing the same stdio. We plan to push all lifecycle scripts to a stdio-piped process, and print stdout/stderr only if it's a failure that we care about (ie, non-zero exit code for non-optional dependency). This will also allow us to prevent interleaved output.

[wesleytodd]

Is there an rfc for this background behavior @isaacs? This might break more than just the fund use case. Not that I think it is bad, I would just like to read and maybe give feedback on it.

[isaacs]

@wesleytodd Hm, I don't see one. It looks like it was added to the roadmap before I switched back to a technical role with the CLI, could've been before the RFC process even started. We can write one up, though.