This is really weird, I have the following scripts in my package.json:
"scripts": {
"lint": "./node_modules/tslint/bin/tslint src/js/**/*",
"lint:fix": "./node_modules/tslint/bin/tslint src/js/**/* --fix"
},
When I run npm run lint I don't get any errors and running echo $? immediately after shows 0.
However, if I run tslint src/js/**/* I do get linting errors.
How come?
There are a host of well-known issues in npm arising from the use of globbing. Many of them exclusively impact Windows, while others are "merely" shell-specific.
Try the following.
"scripts": {
"lint": "./node_modules/tslint/bin/tslint \"src/**/*.ts\"",
},
If this didn't immediately persuade you that computers have been a disaster for the human race, you can learn more about why these issues occur in the fantastic The Linux Programming Interface, which covers a surprising number non-Linux portability issues such as this one.
using npm run lint defaults to the tslint in the node_modules of your local project directory, while using tslint src/js/**/* defaults to the the one in your global, you should check if there is a version mismatch which could cause differences in rules
With npm-run-scripts you can omit the ./node_modules/.bin as npm will first look in there.
Related
I have two types of test suites - normal and coverage.
At present, I am allowing one of them via npm test and one of them via npm start:
"scripts": {
"test": "node scripts/run-truffle-tests.js",
"start": "node scripts/run-sol-coverage.js"
}
I have a feeling that npm start was not originally designated for this purpose.
Is there a better way to implement this?
I was thinking of passing an argument to npm test, but I'm not sure that npm would pass it on to the script which it is set to invoke.
Add more scripts.
I usually have the tests for actual, full, single run unit tests to work with CI and other scripts for variations:
{
"scripts": {
"test": "node scripts/run-truffle-tests.js && npm run test:coverage",
"test:continuous": "karma start some.config --run-continuous",
"test:coverage": "node scripts/run-sol-coverage.js"
"start": "node index.js"
}
}
You can also chain commands with && which will cause the script to be run in sequence and the "total" error code will propagate. In other words, using the test I have above, will run both the unit test and the coverage test. If either of them return a non-zero exit code, npm will consider the whole test process to have failed.
Bear in mind that for custom scripts not named exactly start and test as well as the other designated scripts found in the docs here: npm#scripts, must be run with
npm run scriptname
instead of just
npm scriptname
So in my above example, you would test coverage with:
npm run test:coverage
Also, the : is just a convention. As far as I know it's not special.
Additionally, you can
pass [argument] on to the script which it is set to invoke
Whenever use use npm test, what is basically happening is that npm runs whatever String value is set in the package.json's scripts.test as a process, as though you had typed that String into the shell yourself. It then looks at the return code and if it's 0, it reports as everything being ok; if it's non-zero, it prints an error.
I want to ask the community if they have ever seen this issue before.
when running a simple "npm t" command, I am getting the following error
GTaylor#slayer MINGW64 /d/slayer/packages/components (feature/HUBBLU-54)
$ npm t
> fl-components#1.0.0 test D:\slayer\packages\components
> jest --config=jest.json
s" --config=jest.json was unexpected at this time.
D:\slayer\packages\components>)s" --config=jest.json
npm ERR! Test failed. See above for more details.
the script is
"scripts": {
"build": "tsc -d",
"test": "jest --config=jest.json"
}
If I run the command directly this work. I also have other project (in another solution) that works.
This is a Lerna project with multiple packages and they all suffer from the same issue. Note that this was working on one point.
I have no idea where the "s" is coming from. It feels like it trying to run a following command .. but where the hell is the "s" and new lines coming from????
"jest --config=jest.json\n\ns -config=jest.json"
please help before I go mad.... :)
I just installed ESLint and I can successfully run it by doing this at the terminal window:
./node_modules/.bin/eslint app
Note: app is the root folder I want lint to inspect.
I then put that exact command in my package.json:
"scripts": {
"lint": "./node_modules/.bin/eslint app"
}
I expected to be able to run it in the terminal window like this:
npm run lint
Note: I know how to fix the no-undef error. My question is about the many errors lines after that.
It actually works, but it also produces a bunch of errors after showing me the correct output:
Why is that happening?
This is the default way of how the npm script runner handles script errors (i.e. non-zero exit codes). This will always happen, even if you only run a script like exit 1.
I'm not sure why this feature exists, it seems annoying and useless in most cases.
If you don't want to see this, you can add || true at the end of your script.
Example:
lint: "eslint app || true"
As you might've noticed, I've omitted the part to the eslint binary. The npm script runner already includes local binaries as part of the path when trying to run the script so there is no need to use the full path.
document is a global, so eslint thinks you are missing an import somewhere. For those cases, you can adapt your config so that the error is not reported, Something like this:
module.exports = {
"globals": {
"document": true
}
}
this should be saved as .eslintrc.js and be at the same level where your package.json is
I want to force using yarn install instead of npm install. I want to raise an error in npm install. What should I do in package.json?
UPDATE: Alexander's answer is the better solution and uses the same technique I describe here. I am leaving my answer in tact for posterity. The original point of my answer was to show that you can execute a small node script which should work on all platforms.
In your preinstall script you can run a mini node script which should work on all platforms, whereas things like pgrep (and other common *nix commands and operators) won't work on Windows until Windows 10 has received widespread adoption.
I tested the below script on Node v4.7.0 (npm v2.15.11) and Node v7.2.1 (npm v3.10.10). I assume it works on everything in between. It works by checking the environment variables on the currently running process - the npm_execpath is the path to the currently running "npm" script. In the case of yarn, it should point to /path/to/yarn/on/your/machine/yarn.js.
"scripts": {
"preinstall": "node -e \"if(process.env.npm_execpath.indexOf('yarn') === -1) throw new Error('You must use Yarn to install, not NPM')\""
}
You can read more about npm scripts here: https://docs.npmjs.com/misc/scripts
As far as the npm_execpath environment variable, while not documented I doubt that it will ever change. It's been around for multiple major releases of npm and it doesn't really pass the "there's a better name for this" test.
Most of the answers here involve hacky scripts but there's a built in way to achieve this which I posted over on the Yarn github issue. Unlike soe of the other ways, this works for any and all NPM commands -- actually a bug in npm means it blocks npm install but not npm install <package>. Hopefully though the developers suspicions would already be raised from doing an npm install.
You add a fake engine version like so in package.json (you may want to tweak the yarn and node entries):
"engines": {
"npm": "please-use-yarn",
"yarn": ">= 1.17.3",
"node": ">= 12.5.0"
}
Then you add an .npmrc file to the project root with this:
engine-strict = true
Running NPM then raises an error:
npm ERR! code ENOTSUP
npm ERR! notsup Unsupported engine for root#: wanted: {"npm":"please-use-yarn","yarn":">= 1.17.3","node":">= 12.5.0"} (current: {"node":"12.9.1","npm":"6.10.2"})
npm ERR! notsup Not compatible with your version of node/npm: root#
Like the other answers, I'd recommend using a preinstall script and checking your environment. For a portable solution that won't have false-positives if another npm process happens to be running, using node -e 'JS_CODE' is probably the best option.
In that JS code, you can check the package manager's path using the following:
process.env.npm_execpath
Yarn's binary is yarn.js, compared to npm-cli.js used by NPM. We can use a regex like the following to check that this string ends with yarn.js.
/yarn\.js$/
By using this regex, we can be sure it won't accidentally match somewhere earlier in the file system. Most-likely yarn won't appear in the file path, but you can never be too sure.
Here's a minimal example:
{
"name": "test",
"version": "1.0.0",
"scripts": {
"preinstall": "node -e 'if(!/yarn\\.js$/.test(process.env.npm_execpath))throw new Error(\"Use yarn\")'"
}
}
Of course, the user will still be able to get around this check be editing the JSON or using the --ignore-scripts options:
npm install --ignore-scripts
After trying these options and not being very satisfied, I recommend only-allow.
Just add:
{
"scripts": {
"preinstall": "npx only-allow yarn"
}
}
I like that it provides a clear warning message, and instructions how to install yarn:
Credit to Adam Thomas' answer for providing the thread recommending this.
You can use the preinstall hook along with some shell script to achieve this.
sample package.json:
"scripts": {
"preinstall": "pgrep npm && exit 1"
}
I've just released a module that includes a CLI for this (useful for npm preinstall scripts): https://github.com/adjohnson916/use-yarn
Also, I've just released a helper for Danger to check for missing yarn.lock changes on CI:
https://github.com/adjohnson916/danger-yarn-lock
See also discussion here:
https://github.com/yarnpkg/yarn/issues/1732
https://github.com/alexanderwallin/use-yarn-instead/issues/1
If you want to simply test whether packages are being installed under yarn or npm, I tweaked Alexander O'Mara's answer slightly since it worked for me on OS X:
"scripts": {
"preinstall": "if node -e \"process.exitCode=!/yarn\\.js$/.test(process.env.npm_execpath)\" ; then echo yarn ; else echo npm ; fi",
"postinstall": ""
}
There are quite a few concepts happening in this short snippet:
The \\. portion is escaped so that \\ becomes \ and results in a properly escaped \. to detect a period in the regex.
process.exitCode= can be used to set the process's exit code and is safer than calling process.exit(N) due to the asynchronous nature of Node.js.
In Alexander's example, throw new Error(\"Use yarn\") caused node to exit with code 1 and print the stack trace to stderr. You can try running these on the console to see how that works: node -e 'throw new Error("Oops")' and node -e 'throw new Error("Oops")' 2> /dev/null (which directs the stderr stream to /dev/null). Then you can verify that the exit code was 1 with echo $? (which prints the last exit code).
The shell's if XXXX ; then YYYY ; else ZZZZ ; fi conditional logic checks the exit code of XXXX and goes to the then case for 0 (any other value goes to the else case). So if the regex detects yarn.js at the end of process.env.npm_execpath then it returns true. This must be negated so that the node process exits with code 0 and satisfies the if.
You could also console.log() the regex result and compare the output in the shell (this is just a little more verbose). Here are some examples of how to do that: https://unix.stackexchange.com/a/52801 and https://superuser.com/a/688902
You can append true ; or false ; to any shell statement to set the exit code manually. For example you can try true ; echo $? or false ; echo $?.
You can also leave off the else echo npm ; portion entirely if you don't need it.
With all of that out of the way, you can substitute the echo yarn and echo npm portions with other commands. For example, you could put multiple commands in a subshell like (echo yarn) or echo $(echo yarn).
In my case, I needed to work around an issue where one of the packages installed but had bugs under yarn so I had to run an npm install --ignore-scripts in the success case. Note that this should probably never be done in production, but can be a lifesaver if you just need to get something done or don't have control over which package manager will be used down the road.
I haven't tried this on Windows, so if someone can test the syntax there I will update my answer with what works. It would be best if the preinstall script is identical under both Windows and the Mac/Linux shell.
Found an alternate solution on Reddit. I added this to the end of my .zshenv file:
NPM_PATH=$(which npm)
npm () {
if [ -e yarn.lock ]
then
echo "Please use yarn with this project"
else
$NPM_PATH "$#"
fi
}
It now stops me from absentmindedly running commands like npm i on any yarn project on my Mac.
As some answers have already showed, you can use the only-allow package like so:
{
"scripts": {
"preinstall": "npx only-allow [npm|cnpm|pnpm|yarn]"
}
}
However, NodeJS v16.9.0 and v14.19.0 support a new experimental packageManager field in the package.json file.
Type: <string>
{
"packageManager": "<package manager name>#<version>"
}
The "packageManager" field defines which package manager is expected to be used when working on the current project. It can be set to any of the supported package managers, and will ensure that your teams use the exact same package manager versions without having to install anything else other than Node.js.
This field is currently experimental and needs to be opted-in; check the Corepack page for details about the procedure.
I'm attempting to build a package.json so that when running a NodeJS app on Heroku it will run the scripts.postinstall step using an environment variable. For example:
...
"scripts": {
"postinstall": "command $ENV_VAR"}
},
...
I've looked at the docs and wasn't able to find something saying I can.
Is this even possible? Is this even desirable and "I'm Doing It Wrong"™?
Ignore the nay-sayers. You can do this in a cross-platform manner using cross-var:
"scripts": {
"postinstall": "cross-var command $ENV_VAR"
}
Updated answer due to new packages having been written
You can use the cross-var package to do this in a clean way:
...
"scripts": {
...
"postinstall": "cross-var command $ENV_VAR",
...
},
"dependencies": {
...
"cross-var": "^1.1.0",
...
}
...
Original answer
To answer the last questions, because they're the most important one: yes, no, and absolutely, because you've just broken cross-platform compatibility. There is no guarantee your environment syntax works for all shells on all operating systems, so don't do this.
We have a guaranteed cross-platform technology available to us already: Node. So, create a file called something like bootstrap.js, and then make npm run node bootstrap as your postinstall script. Since the code inside bootstrap.js will run like any other node script, it'll have access to process.env in a fully cross-platform compatible way, and everyone will be happy.
And many, many, many things that use common utils have node equivalents, so you can npm install them, locally rather than globally, and then call them in an npm script. For instance mkdir -p is not cross-platform, but installing the mkdirp module is, and then an npm script like "ensuredirs": "mkdirp dist/assets" works fine everywhere when run as npm run ensuredirs
And for convenience, the most common unix utilities have their own runner package, shx, which is fully cross-platform and makes the lives of devs even easier, with the "if you're writing code" equivalent being fs-extra.