(Node.js) --grpc_out: protoc-gen-grpc: %1 is not a valid Win32 application - node.js

I want to compile my .proto file into stubs, but when entering the command:
`protoc -I=. ./protos/dummy.proto
--js_out=import_style=commonjs,binary:./server --grpc_out=./server --plugin=protoc-gen-grpc=which grpc_tools_node_protoc_plugin
I got the following error :
--grpc_out: protoc-gen-grpc: %1 is not a valid Win32 application.
Thigs I have installed :
Windows 10
npm install -g grpc-tools
npm install google-protobuf
protoc
NOTE: I noticed there are a few similar questions already, but I didn't find one for Node.js, also the already asked questions all have different solutions.

On Windows, I messed around with the grpc-tools for Node a bit and came across some issues. I installed the tools (and the TS plugin) via npm install grpc-tools grpc_tools_node_protoc_ts --save-dev to my local node_modules/.bin folder. Thanks to this post, I can provide these solutions. This was my original shell script
#!/usr/bin/env bash
PROTO_DIR="./src/grpc/proto"
PROTOC_GEN_TS_PATH="./node_modules/.bin/protoc-gen-ts"
GRPC_TOOLS_NODE_PROTOC_PLUGIN="./node_modules/.bin/grpc_tools_node_protoc_plugin"
GRPC_TOOLS_NODE_PROTOC="./node_modules/.bin/grpc_tools_node_protoc"
# Generate JS and corresponding TS d.ts codes for each .proto file using the grpc-tools for Node.
$GRPC_TOOLS_NODE_PROTOC \
--plugin=protoc-gen-grpc="$GRPC_TOOLS_NODE_PROTOC_PLUGIN" \
--plugin=protoc-gen-ts="$PROTOC_GEN_TS_PATH" \
--js_out=import_style=commonjs,binary:"$PROTO_DIR" \
--ts_out="$PROTO_DIR" \
--grpc_out="$PROTO_DIR" \
-I "$PROTO_DIR" \
"$PROTO_DIR"/*.proto
If you just provide the plugin by its name, e.g. --plugin=protoc-gen-grpc=./node_modules/.bin/grpc_tools_node_protoc_plugin, Windows will complain about an invalid Win32 application. You can solve this issue by adding the .cmd extension:
--plugin=protoc-gen-grpc=./node_modules/.bin/grpc_tools_node_protoc_plugin.cmd
Unfortunately, the following issue '.' Not an internal or external command, or a runnable program or batch file arises, which indicates that Windows cannot resolve the relative path to the plugin. Therefore, you have to provide the absolute path, e.g.
--plugin=protoc-gen-grpc=C:/.../<project-dir>/node_modules/.bin/grpc_tools_node_protoc_plugin.cmd
Now the real magic happens:
Because of a simple typo (I typed --plugin=proto-gen-grpc instead of --plugin=protoc-gen-grpc), I figured out that, if you have grpc-tools and additional plugins installed in your local Node environment, you can simply omit --plugin.
It seems that grpc_tools_node_protoc will automatically lookup the executables required to generate the code specified by the output flags --grpc_out, --js_out or --ts_out in ./node_modules/.bin/.
Therefore, I updated the following LOC in my script
$GRPC_TOOLS_NODE_PROTOC \
--js_out=import_style=commonjs,binary:"$PROTO_DIR" \
--ts_out="$PROTO_DIR" \
--grpc_out="$PROTO_DIR" \
-I "$PROTO_DIR" \
"$PROTO_DIR"/*.proto
Maybe, others could share their experience and more clarifications to this issue.

You can solve this issue by adding the .cmd extension:
--plugin=protoc-gen-grpc=./node_modules/.bin/grpc_tools_node_protoc_plugin.cmd
And the following issue '.' Not an internal or external command, or a runnable program or batch file, you can solve replacing the '.' by '%cd%':
--plugin=protoc-gen-grpc=%cd%/node_modules/.bin/grpc_tools_node_protoc_plugin.cmd

SIMPLE SOLUTION :
For me the "which" command was pointing to the wrong path so I removed it and replaced it with an absolute path to the plugin instead. It looks like this :
protoc -I=. ./protos/dummy.proto
--js_out=import_style=commonjs,binary:./server --grpc_out=./server --plugin=protoc-gen-grpc=C:\Users\myUser\AppData\Roaming\npm\node_modules\grpc-tools\bin\grpc_node_plugin.exe
Explanation :
I am not sure why this error (--grpc_out: protoc-gen-grpc: %1 is not a valid Win32 application) was happening, but I have an theory... The "which" command pointed to the folder and not to the .exe file. How do I know this? When I try to only run the command (in the terminal)
which grpc_tools_node_protoc_plugin
It returns the folder
/c/Users/myUser/AppData/Roaming/npm/grpc_tools_node_protoc_plugin

As grpc-tools has been installed globally (-g flag per OP), setting the plugin path beforehand works.
GRPC_TOOLS_PLUGIN="$HOME/AppData/Roaming/npm/grpc_tools_node_protoc_plugin.cmd" && \
protoc -I=. ./protos/*.proto \
--js_out=import_style=commonjs,binary:./server \
--grpc_out=./server \
--plugin=protoc-gen-grpc=$GRPC_TOOLS_PLUGIN
Thanks to both answers before me for pointers!
Tested and found to be working on Windows 10 Pro and Git Bash.

This piece of code worked for me.
protoc --js_out=import_style=commonjs,binary:./server ./proto/dummy.proto

Related

How to generate the _grpc_pb.d.ts from a proto file for use with gRPC in a Node app?

Here is my npm run protoc, the line below will run:
./node_modules/protoc/protoc/bin/protoc --proto_path=proto --js_out=import_style=commonjs,binary:src/bin --grpc_out=src/bin --plugin=protoc-gen-grpc=node_modules/grpc-tools/bin/grpc_node_plugin --ts_out=service=true:src/bin proto/authentication_service.proto
And it generates the following files:
authentication_service_grpc_pb.js
authentication_service_pb.d.ts
authentication_service_pb.js
authentication_service_pb_service.d.ts
authentication_service_pb_service.js
At one time I was able to get it to generate a authentication_service_grpc_pb.d.ts but with the config I saved above it does not. Can anyone help with what I am missing? Thanks!
Take a look at the "How to use" section of the documentation and note that generating the d.ts codes is done with a different executable:
npm install grpc_tools_node_protoc_ts --save-dev
# generate js codes via grpc-tools
grpc_tools_node_protoc \
--js_out=import_style=commonjs,binary:./your_dest_dir \
--grpc_out=./your_dest_dir \
--plugin=protoc-gen-grpc=`which grpc_tools_node_protoc_plugin` \
-I ./proto \
./your_proto_dir/*.proto
# generate d.ts codes
protoc \
--plugin=protoc-gen-ts=./node_modules/.bin/protoc-gen-ts \
--ts_out=./your_dest_dir \
-I ./proto \
./your_proto_dir/*.proto
After writing this, that's not even the root of the problem (at least for this one particular generator). The executable in bin/ is protoc-gen-ts.
When you're trying out different stuff make sure to version-control your attempts and clean out the output directory to have a reproducible environment.
Given all of this my best guess is that the --ts-out and --js-out flags cancel each other out and you'll have to run the generator once for each output type. Verify by trying it out. As a bonus you could try finding out if there's a --verbose flag to make your life easier :).

Shopify's 'slate' package not running after installation

I just installed Shopify's 'Slate' package using npm.
Terminal shows that the package was added to '/.npm-packages/lib'.
However, when I attempt to build a new shopify theme using the command 'slate theme newthemename', the command isn't found...
...even though slate clearly was installed.
Curious to figure out what I'm doing wrong, so any help/advice is much appreciated!
Please execute the below command from your terminal.
npm link #shopify/slate
Basically this command creates a symlink to your package folder, it will check for the global (npm) modules first, and will check for the local modules if there is no match.
Hope this helps!
Your installation of slate is successful. However, the slate program (slate/lib/index.js) is not added to environment variable PATH, that's why error command not found is reported.
To fix this issue, a simple method is add slate/lib/index.js to PATH manually. For example, create a symbolic link in /usr/local/bin/ and make it point to slate/lib/index.js:
sudo ln -s /<absolute_path>/#shopify/slate/lib/index.js /usr/local/bin/slate
Please note the first parameter of ln -s must be absolute path. If relative path is used, Mac OS X (I'm on 10.12.6) won't help to translate it.

Graphviz, gvpr is not recognized

I am trying to use MaDGe to Save dependency graph as a SVG image with CLI command
madge --image graph.svg path/src/app.js
but I face the error 'gvpr' is not recognized as an internal or external command
this is where I have C:\Program Files (x86)\Graphviz2.38\bin in my PATH.
I also tried adding the PATH in both user and system variables but still the same issue
in windows the executable file is called "dot.exe", I had the same issue as you and fixed it by copying & renaming "dot.exe" to "gvpr.exe" in the /bin/folder
works fine now for me.
try to use madge command by windows command propmt (not git bash or something like that)
it's worked for me

Installing Jenkins Plugins to Docker Jenkins

I have the following Dockerfile with jenkins as the base image:
FROM jenkins
USER root
ENV JENKINS_MIRROR http://mirrors.jenkins-ci.org
RUN for plugin in git-client git ws-cleanup ; do wget -O $JENKINS_HOME/plugins/${plugin}.hpi $JENKINS_MIRROR/plugins/${plugin}/latest/${plugin}.hpi ; done
EXPOSE 8080
I'm trying to install some additional plugins but it gives me an error saying no such file or directory
I then started and connected to the container of this build step in order to "debug" the error:
However, I could not find out the cause because every directory seems to exist. Furthermore, if I then run the for-loop manually in the bash, all plugins are installed correctly...
I further noticed, that the installation of the the plugins works, if I install them in the root directory as follows:
RUN for plugin in git-client git ws-cleanup ; do wget -O ${plugin}.hpi $JENKINS_MIRROR/plugins/${plugin}/latest/${plugin}.hpi ; done
However, this is the wrong place as they have to be placed in the directory $JENKINS_HOME/plugins
Why I am not able to install the plugins in $JENKINS_HOME/plugins?
I can't read your screenshots, but you don't seem to be following the official instructions. See https://github.com/cloudbees/jenkins-ci.org-docker under "Installing more tools". Note:
You should save the plugins to /usr/share/jenkins/ref/plugins
You could use a plugins.txt file instead, which contains the names of your plug-ins, and you can process with the provided plugins.sh script. This looks like:
COPY plugins.txt /usr/share/jenkins/plugins.txt
RUN /usr/local/bin/install-plugins.sh < /usr/share/jenkins/plugins.txt
I think the reason your approach wasn't working was to do with some processing in the start-up script.
install-plugins.sh is deprecated. I had to switch to jenkins-plugin-cli:
FROM jenkins/jenkins
...
RUN jenkins-plugin-cli \
--plugins \
git \
workflow-aggregator \
blueocean \
other-plugins
jenkins-plugin-cli also supports -f parameter, which gets the list of plugins as a file.
See Jenkins Official Documentation for details.

Groovy scripts no longer work under Cygwin?

In older versions of Groovy, I could run Groovy as a shell script under Cygwin, following their own instructions for doing so:
$ cat ~/bin/hiworld
#!/usr/bin/env groovy
println("Hello world")
This worked. However, under (at least) Groovy 2.3.2 and 2.3.3, I'm seeing this instead:
$ hiworld
Caught: java.net.MalformedURLException: unknown protocol: c
java.net.MalformedURLException: unknown protocol: c
My best stab in the dark: "env" launches scripts via an absolute path (e.g. "groovy /home/myacct/bin/hiworld"), and newer versions of Groovy have been, un, 'improved' so that Groovy no longer understands how to handle this.
Indeed, I can produce the same error by doing that:
$ groovy ~/bin/hiworld
Caught: java.net.MalformedURLException: unknown protocol: c
java.net.MalformedURLException: unknown protocol: c
So I'm not sure how Groovy is (a) resolving that to a windows-style path, and then (b) failing to understand it's a windows-style path.
I can "fix" this, then, by running it thusly:
$ groovy $(cygpath -w ~/bin/hiworld)
Hello world
... but, c'mon, that's a completely insane way of having users launch a utility script. (Or I could write a "front" script, with just that line, to launch another script, of course. But then, for what I'm trying to ultimately accomplish, I might as well just give up on Groovy and distribute a runnable JAR with an associated launching script.)
So has Groovy simply dropped support for Cygwin? Or is it really possible that they've gone at least two releases without testing their own recommended way of running a script under one of the most popular environments?
If not, what am I missing or doing wrong?
Update: I thought it would be helpful to back up some of the things I'm suggesting here.
First, I want note Cygwin clearly is (or was) at least somewhat supported: groovyStart, for example, has considerable code in it supporting the Cygwin platform (seemingly as much as, say Mac OSX). As noted, it apparently worked fine under previous versions.
Currently, the last example resolves, under groovyStart, to this:
'/cygdrive/c/Program Files/Java/jdk1.7.0_51/bin/java' -classpath C:/cygwin64/home/myacct/opt/groovy-2.3.3/lib/groovy-2.3.3.jar -Dscript.name=/home/myacct/opt/groovy-2.3.3/bin/groovy -Dprogram.name=groovy -Dgroovy.starter.conf=C:/cygwin64/home/myacct/opt/groovy-2.3.3/conf/groovy-starter.conf -Dgroovy.home=C:/cygwin64/home/myacct/opt/groovy-2.3.3 '-Dtools.jar=C:/Program Files/Java/jdk1.7.0_51/lib/tools.jar' org.codehaus.groovy.tools.GroovyStarter --main groovy.ui.GroovyMain --conf C:/cygwin64/home/myacct/opt/groovy-2.3.3/conf/groovy-starter.conf --classpath . C:/cygwin64/home/myacct/bin/hiworld
Just to clarify, there's no problem invoking the JDK itself -- runs that part of the command runs just fine. The part which is broken is the very last argument: if I change
C:/cygwin64/home/myacct/bin/hiworld
to
file:///C:/cygwin64/home/myacct/bin/hiworld
... it works again. This agrees with my assertion above that "groovy" (the script) is indeed correctly converting from Cygwin/UNIX-style paths to a native Windows path, but the underlying process -- running in Windows Java -- is actually confused by having been a windows path! Apparently it was expecting a URL.
Update 2: Below, Warren makes the excellent suggestion of trying to use GVM. Sadly, this still produces the same error:
$ which groovy
/home/myacct/.gvm/groovy/current/bin/groovy
$ hiworld
Caught: java.net.MalformedURLException: unknown protocol: c
java.net.MalformedURLException: unknown protocol: c
$ sh $(which groovy) ~/bin/hiworld
Caught: java.net.MalformedURLException: unknown protocol: c
java.net.MalformedURLException: unknown protocol: c
Adding the "-x" flag to the previous command shows that Groovy is still using my Windows JVM (which isn't wrong, just noting) and is now referencing the GVM-installed libraries (shown here reformatted slightly for readability):
'/cygdrive/c/Program Files/Java/jdk1.7.0_51/bin/java' \
-classpath C:/cygwin64/home/myacct/.gvm/groovy/2.3.3/lib/groovy-2.3.3.jar \
-Dscript.name=/home/C400334/.gvm/groovy/current/bin/groovy \
-Dprogram.name=groovy \
-Dgroovy.starter.conf=C:/cygwin64/home/myacct/.gvm/groovy/2.3.3/conf/groovy-starter.conf \
-Dgroovy.home=C:/cygwin64/home/myacct/.gvm/groovy/2.3.3 \
'-Dtools.jar=C:/Program Files/Java/jdk1.7.0_51/lib/tools.jar' \
org.codehaus.groovy.tools.GroovyStarter \
--main groovy.ui.GroovyMain \
--conf C:/cygwin64/home/myacct/.gvm/groovy/2.3.3/conf/groovy-starter.conf \
--classpath . \
C:/cygwin64/home/myacct/bin/hiworld
As before, adding a "file:///" before the final argument seems to resolve the problem.
So I'm wondering perhaps if we're using a different version of the JVM or something?
Update 3: Upgrading to jdk1.7.0_60 (tried both 64- and 32-bit versions) but that didn't seem to make a difference. Java 6 exhibits the same problem, but also adds a complaint about missing NioGroovyMethods.
I'm not sure how Groovy is (a) resolving that to a windows-style path
The startGroovy script has specific code in it to detect Cygwin and use cygpath as necessary.
I discovered this by installing Groovy via GVM, the approved way of getting Groovy for Unixy platforms. (You do not want to use the native Windows distribution of Groovy in this case!)
The only tricky thing was figuring out how to set JAVA_HOME. Here, it needed to be:
$ export JAVA_HOME='/cygdrive/c/Program Files (x86)/Java/jre7'
If you're on a 64-bit version of Windows and have a 32-bit JRE installed as I do, this should also work for you. Otherwise, you may have to adjust the path.
Once I got gvm install groovy to succeed, your hiworld example worked fine here if I ran it as ./hiworld. This was with the 32-bit version of Cygwin with Java 1.7.0_55.
However, when I put it in the PATH and ran it as hiworld, as you are doing, this passed a fully-qualified path to the groovy wrapper script (e.g. /home/wyoung/bin/hiworld) instead of a relative path, which caused the startGroovy script to run the path through cygpath -m, which turns that into something like C:/cygwin64/home/wyoung/bin/hiworld. Oracle's JRE can't cope with forward slashes in local paths. It blindly assumes that forward slashes on Windows means it's a URL of some kind, so C: gets treated as the URL scheme, or "protocol" as they put it.
I don't know if this is a regression in Java or in the startGroovy script. Although you could pass a file:// URL here as you discovered, you can also pass a "proper" Windows path with backslashes instead of forward slashes. You get that from cygpath with the -w switch instead of -m. You have to be a lot more careful about avoiding accidental backslash escaping in this case, which may explain the regression.
Just hit the same problem and changed the exec call in the startGroovy script to the following (note the last two lines):
exec "$JAVACMD" $JAVA_OPTS \
-classpath "$STARTER_CLASSPATH" \
-Dscript.name="$SCRIPT_PATH" \
-Dprogram.name="$PROGNAME" \
-Dgroovy.starter.conf="$GROOVY_CONF" \
-Dgroovy.home="$GROOVY_HOME" \
-Dtools.jar="$TOOLS_JAR" \
$STARTER_MAIN_CLASS \
--main $CLASS \
--conf "$GROOVY_CONF" \
--classpath "$CP" \
"$(cygpath -w $1)" \
"${#:2}"
... that way the script being called is altered to a windows path with backslashes as suggested above, and then not interpreted as a URL it seems. Nasty hack, but at least I was able to execute my script again :)
Not sure if anyone still interests in this. But shortly I commented the above answer, I found a solution for this.
Update the "startGroovy" script with the following two changes:
for dir in $ROOTDIRSRAW ; do
ROOTDIRS="$ROOTDIRS$SEP$dir"
SEP="|"
done
ROOTDIRS="/c$SEP$ROOTDIRS" ## <<<< ADD THIS LINE;assuming cygwin on c: drv
and also replace the --mixed with --windows:
CHECK=`echo "$arg"|egrep -c "$OURCYGPATTERN" -`
if [ $CHECK -ne 0 ] ; then
### change the --mixed to --windows here
patched=`cygpath --path --ignore --windows "$arg"`
else
patched="$arg"
fi
and it should work.

Resources