With npm, you can pass random arguments like this:
npm run build --foo="bar"
You can then access foo value this way:
process.env.npm_config_foo
Is it possible to do the same with pnpm? I looked in their docs but couldn't find anything on that. I tried something like this but getting unknown flag error
pnpm build --foo=bar
I am not sure why it throws an error. Sounds like a bug. However, this will work:
pnpm run build --foo=bar
But it will not create the npm_config_foo env variable. It will just append the option to the executed script. So if your build script is webpack, then pnpm will run:
webpack --foo=bar
So, it is basically like running npm run build -- --foo=bar. Or like running yarn build --foo=bar
You can read about this also in the pnpm docs: https://pnpm.io/cli/run#options
Related
script object in the package.json files is the modern replacement for Gulp or a similar build tool. Assume that Vuepress is installed with yarn add -D vuepress (meaning that the vuepress is installed locally in the node_modules folder.
Further, assume that the package.json file contains the following script object:
"scripts": {
"docs:dev": "vuepress dev docs",
"docs:build": "vuepress build docs"
}
How does the command yarn docs:dev executed in the terminal resolve the vuepress object? More often than not a similar invocation results with the error vuepress not recognized ...
P.S. Since I do not have vuepress in the path environment variable the only place where it can be resolved is in the root level node_modules folder.
I guessed correctly - both npm and yarn (invoked from the terminal) have the ability to inspect all environment variables, as well as search the folder node_modules. In my concrete example, running the command
npm run env | grep scripts
results with
npm_config_ignore_scripts=
npm_config_scripts_prepend_node_path=warn-only
npm_package_scripts_docs_build=vuepress build docs
npm_package_scripts_docs_dev=vuepress dev docs
npm_package_scripts_env=env
There is a lot more information in the article https://techsparx.com/nodejs/tools/npm-build-scripts.html
I am having trouble understanding how the -g flag works in NPM. Specifically I'm struggling to understand how it relates to command-line functionality exposed by NPM modules.
I assumed that the difference between installing a package locally and globally was simply that a local package would not be available outside of the particular project. And of course that a globally installed package would be available in any project. I'm from a Rails background so this for me would be similar to installing a gem into a particular RVM versus installing it into the global RVM. It would simply affect which places it was available.
However there seems to be more significance than just scope in NPM. For packages that have command-line functionality, like wait-on, the package (as far as I can tell) is not available on the command line unless it's installed globally.
Local install doesn't make the command-line functionality available:
$ npm install wait-on
$ wait-on
=> -bash: /usr/local/bin/wait-on: No such file or directory
Global install does expose the command-line functionality
$ npm install wait-on -g
$ wait-on
=> Usage: wait-on {OPTIONS} resource [...resource]
Description:
wait-on is a command line utility which will wait for files, ports,
sockets, and http(s) resources to become available (or not available
using reverse flag). Exits with success code (0) when all resources
are ready. Non-zero exit code if interrupted or timed out.
Options may also be specified in a config file (js or json). For
example --config configFile.js would result in configFile.js being
required and the resulting object will be merged with any
Can you expose the command-line functionality using a local install?
Is it possible to install locally but also get the command line functionality? This would be very helpful for my CI setup as it's far easier to cache local modules than global modules so where possible I'd prefer to install locally.
If you are using npm 5.2.0 or later, the npx command is included by default. It will allow you to run from the local node modules: npx wait-on
For reference: https://www.npmjs.com/package/npx
I think you can access locally installed modules from the command line only if you add them to your "scripts" section of your package.json. So to use the locally installed version of wait-on, you can add an entry in "scripts" section of package.json like so "wait-on": "wait-on". Then to run it, you would have to do npm run wait-on. You can also do "wo": "wait-on" and then do npm run wo basically meaning what comes after the run is the script entry. In node_modules, there is a .bin folder and inside of this folder is all the executables that you can access this way.
Installing locally makes the package available to the current project (where it stores all of the node modules in node_modules). This is usually only good for using a module like so var module = require('module'); or importing a module.
It will not be available as a command that the shell can resolve until you install it globally npm install -g module where npm will install it in a place where your path variable will resolve this command.
You can find a pretty decent explanation here.
It is also useful to put commands in the scripts block in package.json as it automatically resolve local commands. That means you could have a script that depended on a package without having an undocumented dependency on the same.
If you need to run it locally on cmd, you have to go inside the node_modules and run from the path.
In my package.json file I've got script entry that runs graphql-codegen but it complains that the --config argument is invalid:
$> yarn gen
yarn run v1.21.1
$ graphql-codegen --config codegen.yml
Error: Unknown argument: config
...
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
Since I believe the default file name is codegen.yml anyway, I try to run it with out that argument and nothing gets generated:
$> yarn graphql-codegen
yarn run v1.21.1
$ /home/aaron/projects/my_app/node_modules/.bin/graphql-codegen
Done in 0.17s.
Any ideas?
for me this solved the issue
Yarn
yarn add -D #graphql-codegen/cli
npm
npm i -D #graphql-codegen/cli
installation guide doc
Ok, I'm not sure exactly what I did to fix this. I believe that I had also installed graphql-codegen globally and tried to uninstall it with sudo npm uninstall graphql-codegen which removed a bunch of packages but the executable still exists:
$>which graphql-codegen
/usr/bin/graphql-codegen
However I decided to run yarn graphql-codegen init on a whim to see if init was valid and because I couldn't remember if I hadn't tried that already. I got the set up questions like normal so I ctrl+C'ed and just ran yarn graphql-codegen and it worked! Then I ran yarn graphql-codegen --watch to test that it took options and that also worked.
If anyone gets this issue, I hope these tips help you.
Try it: rm -rf ./node_modules && npm install
rm http://manpages.ubuntu.com/manpages/trusty/man1/rm.1.html
remove files or directories
-f, --force ignore nonexistent files and arguments, never prompt
-r, -R, --recursive remove directories and their contents recursively
node_modules https://docs.npmjs.com/cli/v7/configuring-npm/folders
You can think of the node_modules folder like a cache
for the external modules that your project depends upon. When you npm
install them, they are downloaded from the web and copied into the
node_modules folder and nodejs is trained to look for them there when
you import them (without a specific path).
npm install https://docs.npmjs.com/cli/install/
This command installs a package and any packages that it depends on.
If the package has a package-lock, or an npm shrinkwrap file, or a
yarn lock file, the installation of dependencies will be driven by
that, respecting the following order of precedence:
npm-shrinkwrap.json
package-lock.json
yarn.lock
Might also be that you have apollo's graphql-codegen package installed, which also exposes a binary called graphql-codegen, which accepts args schema and output, but not config.
For me the solution was to install #graphql-codegen/cli.
graphql.config.yml
schema: http://localhost:8081/graphql
extensions:
codegen:
generates:
./schema.graphql:
- schema-ast
package.json
{
"codegen": "graphql codegen --config graphql.config.yml"
}
I've fixed the problem by using graphql-code-generator instead:
"scripts": {
"graphql:generate": "graphql-code-generator"
}
When using the node.js build-pack in heroku, the postinstall hook in package.json can be used to run a custom build script
But what if I am not using the node build-pack? For example, if I am using the apt build-pack, how do I specify a custom build script? Do I still need to create a package.json file just to be able to have this capability?
I had a similar problem, in that I had two buildpacks on my application, one of which was nodejs. My package.json build script was getting run before my python dependencies had been installed, and was failing (I think the same thing would happen with postinstall). The solution was to reverse the buildpack order, and put the python one before the nodejs one, so the build script would have all necessary dependencies.
That same solution could apply here as well, using something like heroku-buildpack-shell. Just put that buildpack last, and stick your build script in .heroku/run.sh.
I tried running shell-basic but nothing happens. Here is what I tried:
To run this example, download and install it with go get:
go get goroutines.com/shell-basic
which finishes silently and I see it downloaded the shell basic script but when i execute shell-basic i get:
$ shell-basic
-bash: shell-basic: command not found
did I do something wrong, or am i missing something?
what i'm interested in is running go as scripts..
go get will fetch the source and put it in your Go path, try echo $GOPATH in the shell. This is what happens if go get finishes silently.
Then you want to go to that source:
cd $GOPATH/src/goroutines.com/shell-basic
aftwards, you must run go install inside the repo. (or you can run go install /path/to/the/code.
The source will then be put in $GOPATH/bin, and be executable.
Of course none of this will work if you don't have you GOPATH set up.
I think you not set GOBIN.
You can follow：
export PATH=$PATH:$GOPATH/bin
Or, try run $GOPATH/bin/shell-basic.Use your gopath replace $GOPATH.