3 ms·
You could make this actually useful by making it read a .env file to set the environment, instead of what people always do, which is: > "test": "NODE_ENV=test
by wokwokwok 5y ago
You could make this actually useful by making it read a .env file to set the environment, instead of what people always do, which is:
> "test": "NODE_ENV=test mocha --reporter spec"
(and doesn't work across platforms like windows)
Or added functionality like being able to pipe the output to multiple places (eg. terminal and log file).
That would offer perhaps a slightly more compelling use-case than saving 200ms; I don't care about that much, I honestly doubt anyone else does either.
The spawn time for an npm compared to the runtime for an npm task are orders of magnitude different, surely, for any non trivial task.
- Cu3PO42 5y ago"NODE_ENV=test mocha --reporter spec" actually works on Windows when using recent versions of Yarn. They implemented a minimal shell parser for this and similarly basic features.
- tentacleuno 5y agoA lot of people use cross-env[0] for that in NPM. You basically turn this: "start": "NODE_ENV=production node ./index.js" To... "start": "cross-env NODE_ENV=PRODUCTION node ./index.js" I'm glad Yarn supports this natively, though. It seems silly to rely on an external package for something so basic (especially with the security vulnerabilities of the ecosystem as a whole). [0]: https://www.npmjs.com/package/cross-env https://www.npmjs.com/package/cross-env
- berkes 5y ago> NOTICE: cross-env still works well, but is in maintenance mode. Which is why I recently kicked all the cross-env out of my nodejs projects and replaced it with Ruby's dotenv[0] (in projects that already used ruby alongside) and zenv[1], in Rust for projects that don't. Basically "start": "zenv --file .env.production -- node ./index.js" [0] https://github.com/bkeepers/dotenv https://github.com/bkeepers/dotenv [1] https://lib.rs/crates/zenv https://lib.rs/crates/zenv (readenv is an alternative, but that doesn't allow overriding the .env file)