Closed jekozyra closed 2 years ago
@jekozyra
Thrilled of what you did here! Thank you for the PR i really appreciate it ! You are one of the few dudes in my whole open source career that help me to manage these libraries! Big respect!
I am checking it at the moment !
I'm not sure about building the packages - the commands fail for me on osx. I haven't tested this in CI, but I did npm link and verify that I could deploy from my local machine with this package.
I think it is coming from npm run build
command where we have npx parcel
, since npx will take the latest version of parcel but some things inside Parcel@2 needs additional configuration which i think we should suppose to provide since it should be automatically like Parcel@1. Anyway i have put specific version for the actual build inside package.json npx parcel@1.12.3 ...
This is why you have also added inside .gitignore
the new cache folder from parcel which is cool! :)).
Cheers!
Issue
Description
In
exitHandler
, we callprocess.exit()
without a code. This means that we default to 0, which indicates success. However, we have no way of knowing if the final command succeeded or not based on that, because we don't attempt to do anything with the result of the command and just assume success. Therefore, we should alter the behaviour to pass the success status of the final command toexitHandler
so that the script exits with the appropriate code.Type of change
Checklist:
runCommand
helper to execute the final command (makes mocking for tests easier)exitHandler
so that finalprocess.exit
call reflects the status of the scriptrunCommand
to exitHandler so iffirebase
call fails, we knowNotes (specific implementation details)
I'm not sure about building the packages - the commands fail for me on osx. I haven't tested this in CI, but I did
npm link
and verify that I could deploy from my local machine with this package.