Generic error message issued for the Java based platform when java is not installed
juj opened this issue · comments
STR:
echo { "dependencies": { "google-closure-compiler": "20220301.0.0" } } > package.json
npm install --no-optional
Then try invoking any Closure Compiler command, e.g.
node_modules\.bin\google-closure-compiler
node_modules\.bin\google-closure-compiler --version
node_modules\.bin\google-closure-compiler --help
node_modules\.bin\google-closure-compiler --platform=java --help
node_modules\.bin\google-closure-compiler --platform=java --version
npx google-closure-compiler
but they will all silently fail and directly return to command prompt, with Windows %ERRORLEVEL% status of -4058, and no errors or other diagnostics messages printed to console.
Tested on Windows without Java in PATH.
Expected: Presumably omitting --no-optional will only install the Java version, so execution should fail with an error message "Java not installed." instead of silently failing.
I don't 100% know if the issue is caused by missing Java, but I am assuming so in the lack of better information.
npm list gives:
E:\test>npm list
E:\test
`-- google-closure-compiler@20220301.0.0
+-- chalk@2.4.2
| +-- ansi-styles@3.2.1
| | `-- color-convert@1.9.3
| | `-- color-name@1.1.3
| +-- escape-string-regexp@1.0.5
| `-- supports-color@5.5.0
| `-- has-flag@3.0.0
+-- google-closure-compiler-java@20220301.0.0
+-- UNMET OPTIONAL DEPENDENCY google-closure-compiler-linux@20220301.0.0
+-- UNMET OPTIONAL DEPENDENCY google-closure-compiler-osx@20220301.0.0
+-- UNMET OPTIONAL DEPENDENCY google-closure-compiler-windows@20220301.0.0
+-- minimist@1.2.5
+-- vinyl@2.2.1
| +-- clone@2.1.2
| +-- clone-buffer@1.0.0
| +-- clone-stats@1.0.0
| +-- cloneable-readable@1.1.3
| | +-- inherits@2.0.4
| | +-- process-nextick-args@2.0.1
| | `-- readable-stream@2.3.7
| | +-- core-util-is@1.0.3
| | +-- inherits@2.0.4 deduped
| | +-- isarray@1.0.0
| | +-- process-nextick-args@2.0.1 deduped
| | +-- safe-buffer@5.1.2
| | +-- string_decoder@1.1.1
| | | `-- safe-buffer@5.1.2 deduped
| | `-- util-deprecate@1.0.2
| +-- remove-trailing-separator@1.1.0
| `-- replace-ext@1.0.1
`-- vinyl-sourcemaps-apply@0.2.1
`-- source-map@0.5.7
Running a regular npm install without the --no-optional flag will avoid the issue. In that case, npm list returns
E:\test>npm list
E:\test
`-- google-closure-compiler@20220301.0.0
+-- chalk@2.4.2
| +-- ansi-styles@3.2.1
| | `-- color-convert@1.9.3
| | `-- color-name@1.1.3
| +-- escape-string-regexp@1.0.5
| `-- supports-color@5.5.0
| `-- has-flag@3.0.0
+-- google-closure-compiler-java@20220301.0.0
+-- UNMET OPTIONAL DEPENDENCY google-closure-compiler-linux@20220301.0.0
+-- UNMET OPTIONAL DEPENDENCY google-closure-compiler-osx@20220301.0.0
+-- google-closure-compiler-windows@20220301.0.0
+-- minimist@1.2.5
+-- vinyl@2.2.1
| +-- clone@2.1.2
| +-- clone-buffer@1.0.0
| +-- clone-stats@1.0.0
| +-- cloneable-readable@1.1.3
| | +-- inherits@2.0.4
| | +-- process-nextick-args@2.0.1
| | `-- readable-stream@2.3.7
| | +-- core-util-is@1.0.3
| | +-- inherits@2.0.4 deduped
| | +-- isarray@1.0.0
| | +-- process-nextick-args@2.0.1 deduped
| | +-- safe-buffer@5.1.2
| | +-- string_decoder@1.1.1
| | | `-- safe-buffer@5.1.2 deduped
| | `-- util-deprecate@1.0.2
| +-- remove-trailing-separator@1.1.0
| `-- replace-ext@1.0.1
`-- vinyl-sourcemaps-apply@0.2.1
`-- source-map@0.5.7
@ChadKillingsworth wrote:
Can you move this issue over to the https://github.com/google/closure-compiler-npm repo?
That's where all the npm related code resides. Also with what you list out, this may be working
as designed. There isn't a good way to detect whether Java is available or not without simply
trying to invoke it. The error received from invoking an executable that doesn't exist is pretty
platform dependent.
this may be working as designed
I would have expected to get an error message explaining to user that the failure to run was due to missing Java. As it currently stands, there is no way to figure that out, except to magically know that code -4058 means "missing Java", but those codes aren't documented anywhere in Closure compiler?
Searching for a Win32 error code -4058 or 0xfffff026 does not find any hits. Attempting to interpret that code as unsigned 4058, here, https://docs.microsoft.com/en-us/windows/win32/debug/system-error-codes--4000-5999- , gives
PEERDIST_ERROR_ALREADY_EXISTS
4058 (0xFDA)
An element already exists and was not replaced.
which does not look related.
The error received from invoking an executable that doesn't exist is pretty platform dependent.
The error that is returned from invoking an executable that doesn't exist sure can be platform dependent, but I don't think Closure should leak any internal subprocess spawn errors transparently through to the user, since users should not be expected to be white box aware of the internal details of how Closure operates under the hood?
Closure should catch any errors during its operation, and transform those errors into meaningful errors in the context of the caller, and document the error codes that it returns.
Running nonexistent Java on Windows does not give error -4058, but instead gives error 9009:
so Closure compiler is not at least directly passing through the error to invoke Java here. (see https://stackoverflow.com/questions/23091906/official-ms-reference-for-cmd-exe-errorlevel-9009 for documentation on error 9009)
Attempting to use Microsoft Error Lookup Tool to identify the error code -4058 does not find a Microsoft specific hit:
so the error code looks like something else.
There are a lot of potential error states and unfortunately many are OS specific. In addition to Java just missing, you have wrong versions, incorrect permissions and I'm sure there are several more.
Detecting whether Java is installed or not is rather difficult. I specifically avoided including other package dependencies to help with this case. We also don't want a performance penalty for something that is essentially a one-time-per-system check.
We're happy to review pull requests to improve these error messages as long as they meet the criteria I outlined.
Since this is essentially a feature request and not an actual bug, I'm going to close this issue. We're definitely open to PRs improving this experience though.