this is my first question ever on StackOverflow.
I am a Mac user and I can normally run multiple command-line commands simply by using & e.g.
gulp & 11ty/eleventy --serve
I have been informed that this doesn't work on Windows. But this does work on Windows:
gulp "&" 11ty/eleventy --serve
Therefore, in my package.json I’ve had to do this (below), and it doesn't look so smart, to me:
"scripts": {
"dev": "gulp & npx #11ty/eleventy --serve",
"dev-win": "gulp \"&\" npx #11ty/eleventy --serve"
}
Is there a better way? one way that works for both Mac and Windows terminals?
Related
I am trying to understand how to be able to set the NODE_ENV variable during my start script in node. I am using a windows machine and I have seen some answers about this for mac/linux but I cannot figure it out on windows (disclaimer: I am new to windows shell scripting).
Currently I have this:
"scripts": {
"serve_dev": "set NODE_ENV=development && nodemon index.js",
},
Which does not work. I have also tried adding $env:NODE_ENV... and that did not work as well. Does someone know how I can do this?
Thanks in advance for any help!
I have resolved this issue and it was due to the spaces. The correct implimentation is:
"scripts": {
"serve_dev": "set NODE_ENV=development&&nodemon index.js",
},
I follow this post to configure NextJs to use absolute paths, like this:
//package.json:
...
"scripts": {
"dev": "NODE_PATH=. next",
"build": "NODE_PATH=. next build",
"start": "next start"
},
NodeJs, npm and nextJs app are up to date both on windows and Linux.
It works on Linux, but when i try to build on a Windows, it fails with the error
'NODE_PATH' is not recognized as an internal or external command, operable program or batch file.
Update
I find out that npm is just running SO scripts, so in windows, the equivalent for:
NODE_PATH=. next
wold be:
set NODE_PATH=. & next
But doesn't work because the command set does not affect the context of the second command
set X=1 & echo %X% returns
%X% //for first run. doesn't consider it a variable because doesn't know her
1 //for second run
Can't figure out how to overcame this last problem
works from outside:
>set NODE_PATH=.
>npm run dev
Should be some better solution somewhere
I'm using visual studio code on Windows 10, with jasmine and nodemon
How does one set up their package.json such that you can run jasmine continuously, yet also be able to drop breakpoints in visual studio code to debug? I feel like I've been searching for ages on how to do some kind of setup like this.
Here is what I currently have in package.json. Running this allows me to write in my .spec files and jasmine gets continualy run on each change:
"scripts": {
"test": ".\\node_modules\\.bin\\nodemon --inspect --ext js --exec \".\\node_modules\\.bin\\jasmine\""
},
Anyone have a magical command to allow debugging any spec file, or any file which the tests execute against?
I'm writing an app that is composed of microservices (I use micro).
I really like es6, so I use Babel to make the development process easier. The problem that I have is that I need a script that would compile my es6 code and restarted the 'server'; I don't know how to achieve this.
Right now I have the following script in my package.json:
"scripts": {
"start": "yarn run build && micro",
"build": "./node_modules/.bin/babel src --out-dir lib"
},
When I run yarn start my es6 code compiles successfully and micro starts the server. However, if I make changes to my code, I'll have to manually stop the server and run yarn start again.
I've tried to change my build script
"build": "./node_modules/.bin/babel src --watch --out-dir lib"
But in this case the micro command does not get executed as the build script just watches for changes and blocks anything else from execution. My goal is to have a script that would watch for changes and restart the server if a change occurred (compiling the code beforehand) like in Meteor.
One option is using ParallelShell module to run shell commands in parallel. You can find an example of how to use it here
The simplest solution would be to yarn run build & micro (note the single & and not &&).
As mentioned by others, parallelshell is another good hack (probably more robust than &).
I noticed this strange behavior which is not a big deal, but bugging the heck out of me.
In my package.json file, under the "scripts" section, I have a "start" entry. It looks like this:
"scripts": {
"start": "APPLICATION_ENV=development nodemon app.js"
}
typing npm start on a Mac terminal works fine, and nodemon runs the app with the correct APPLICATION_ENV variable as expected. When I try the same on a Windows environment, I get the following error:
"'APPLICATION_ENV' is not recognized as an internal or external command, operable program or batch file."
I have tried the git-bash shell and the normal Win CMD prompt, same deal.
I find this odd, because typing the command directly into the terminal (not going through the package.json script via npm start) works fine.
Has anyone else seen this and found a solution? Thanks!!
For cross-platform usage of environment variables in your scripts install and utilize cross-env.
"scripts": {
"start": "cross-env APPLICATION_ENV=development nodemon app.js"
}
The issue is explained well at the link provided to cross-env. It reads:
Most Windows command prompts will choke when you set environment variables with NODE_ENV=production like that. (The exception is Bash on Windows, which uses native Bash.) Similarly, there's a difference in how windows and POSIX commands utilize environment variables. With POSIX, you use: $ENV_VAR and on windows you use %ENV_VAR%.
I ended up using the dotenv package based on the 2nd answer here:
Node.js: Setting Environment Variables
I like this because it allows me to setup environmental variables without having to inject extra text into my npm script lines. Instead, they are using a .env file (which should be placed on each environment and ommitted from version control).
You should use "set" command to set environment variables in Windows.
"scripts": {
"start": "set APPLICATION_ENV=development && nodemon app.js"
}
Something like this.