I am following the guide from here on a nextjs application. Using VSCode on windows.
It says use the script:
"dev": "NODE_OPTIONS='--inspect' next dev"
this results in:
'NODE_OPTIONS' is not recognized as an internal or external command,
operable program or batch file.
Yes I know there is already a question with the same name but it is 2.5 years old, has 8k views and no accepted answer. I am unable to comment to add information to it. Feel free to mark this as a duplicate but please at least link it in a comment in the other question.
The one answer that is there advises installing yet another (maintenance mode) dependency and configuring it to change environment variables.
This and other research leads me to believe that there is an issue with environment variables here. Can't I just set them manually? Why is this not mentioned in the official next guide? How can I set the correct environment variable?
There is a way to get it working and you can find a similar question posted here.
Step 1
npm i cross-env --save-dev
Step 2
Edit your package.json so the dev option looks like this
{
"scripts": {
"dev": "cross-env NODE_OPTIONS='--inspect' next dev",
"build": "next build",
"start": "next start"
}
}
Step 3
You can now launch your NextJS program in a separate terminal. After that follow the NextJS VSCode debugging instructions. Attach VSCode to the running NextJS instance.
You're all set.
Maybe this can help us
Debugging on Windows
Windows users may run into an issue when using NODE_OPTIONS='--inspect' as that syntax is not supported on Windows platforms. To get around this, install the cross-env package as a development dependency (--dev with NPM or -D for Yarn) and replace the dev script with the following.
"dev": "cross-env NODE_OPTIONS='--inspect' next dev",
cross-env will set the NODE_OPTIONS environment variable regardless of which platform you are on (including Mac, Linux, and Windows) and allow you to debug consistently across devices and operating systems.
Related
I used the CLI to install React Native, Node and Python but was not aware if I needed to save it to a file first.
I ran the yarn command:
➜ ~yarn add <package>
I would get this warning message when running yarn check:
➜ ~ yarn check
warning package.json: No license field
warning No license field
warning "jest-haste-map#fsevents#node-pre-gyp#^0.12.0" could be deduped from "0.12.0" to "node-pre-gyp#0.12.0"
Questions:
1. Do I only ~ yarn add when I start a project?
2. Since I've installed python, node, and react-native without creating a project folder will I run into issues down the road?
3. Do I add the json file with the licenses manually when starting a project with yarn?
4. Am I hopeless? lol
I've tried uninstalling and reinstalling from yarn and updating yarn. Also, I've tried installing python and node from Homebrew to see if that changes anything.
Below is a log of the output from the CLI after running ~ yarn check
Last login: Sat Aug 24 02:21:38 on ttys001
➜ ~ yarn check
yarn check v1.17.3
warning package.json: No license field
warning No license field
warning "jest-haste-map#fsevents#node-pre-gyp#^0.12.0" could be deduped from "0.12.0" to "node-pre-gyp#0.12.0"
success Folder in sync.
✨ Done in 1.99s.
Solution I figured it out! So after poking around I realized that once I started a project I had a yarn.lock and package.json file one level up in the directory where the file was located. What I did was I deleted yarn.lock and package.json associated with the folder in the directory. After that was complete I then went into my project and installed the correct packages.
You're not hopeless. This project may be, you've bitten off waaaay more than you can chew yet.
To answer your main question:
yarn add and it's cousin npm install will install the thing you tell them to in the node_modules folder in the directory you run the command in. The reason it's yelling at you is because usually you'll want to save the thing you installed as a dependency of your project, and you can't do that without a package.json file. You should run npm init to set up the package.json file for your project, then running yarn add will actually save it to the dependencies list so that you have a reproducible. If you have a package.json file already, it sounds like you maybe created it by hand (since it's missing a license field?) rather than have npm set it up for you, which is a bad idea.
Two more things:
React Native is awesome! ...But, it's a tool for people who already have good familiarity with Javascript command line/tooling/ecosystem/coding/React to build mobile apps. It is a lousy choice for a first project if you're just getting started with programming. Building a webpage with React is a lot easier, but even that may be too much.
If you really want to build a React Native app and you just can't wait look at this to get started.
But seriously, learn Javascript then npm then yarn then React then React Native. In that order.
I have recently started using npm (https://www.npmjs.com) and it's wonderful that we can use npm as build tool. But after digging much, I got question in my mind.
As a building tool, npm is almost like shell program(sh or bash), because we just execute shell commands in npm package.json file. And even sometimes we execute shell program from it.
EDIT: here is an example how I use it.
package.json
{
"name": "myproject",
"devDependencies": {
"jshint": "latest",
"minify": "latest",
"mocha": "latest"
},
"scripts": {
"lint": "jshint **.js",
"test": "mocha test/",
"minify":"minify *.js",
"build":"npm run lint && npm run test && npm run minify"
}
}
So, everything we're doing with npm bundling facility, we can achieve by writing normal shell program(sh or bash). I want to know what are special advantages of npm over nprmal shell program. What we can't do with shell script, which we can achieve with npm as build tool.
There must be some special vision behind developing tool. Otherwise everything we can do with shell program (Makefile).
Your answer will be appreciated.
Thanking in advance!
Npm as a build tool: do you mean the npm scripts feature? Or something like Grunt or Gulp?
Npm itself is just a package ecosystem for JavaScript (Node) packages. Shell is, well, shell. You can create shell programs with anything which can be run using a shell (Bash, C, Python, PHP, and so on). I presume you mean shell languages like sh or bash in your question.
If you develop Node or browser applications, or use a tool such as Gulp, Grunt, Fly, npm scripts and so on then npm is a good (mandatory) pick.
If you need to create build procedures for something really custom or lower level than regular applications, then custom shell builders or maybe Makefiles could be a better fit. Though some people seem to use Makefiles in places where npm and a build tool like Gulp would be a simpler choice.
What are you building with npm right now which got you questioning the usage of it?
I would like to have Heroku build my app after I push it so that I don't have to push the build folder up every time I make a change. However Heroku only installs the dependencies from the package.json and grunt (my build tool) and all of its components are in devDependencies. I would like to keep them there where they belong. What's the workaround here?
UPDATE: as pointed out in the comments this is no more needed because since 2018 heroku changed its default behaviour and dev dependencies are automatically installed
ORIGINAL ANSWER
Heroku by default installs only the production dependencies, ignoring the development dependencies under devDependencies.
Setting the npm production variable to false do the trick:
heroku config:set NPM_CONFIG_PRODUCTION=false
More info are available at the Heroku Node.js Support page.
Keeping NPM_CONFIG_PRODUCTION true, I used Heroku's script hooks:
"scripts": {
...
"heroku-prebuild": "export NPM_CONFIG_PRODUCTION=false; export NODE_ENV=; NPM_CONFIG_PRODUCTION=false NODE_ENV=development npm install --only=dev --dev",
"heroku-postbuild": "export NPM_CONFIG_PRODUCTION=true; export NODE_ENV=production;",
...
},
(Finally) worked for me.
scripts": {
...
"heroku-prebuild": "npm install --only=dev"
}
This was enough for me. Thanks to PixnBits for the hint about heroku-prebuild.
Also - my problem was with babel. I ended up moving babel-preset-es2015 and other presets into dependencies otherwise babel complained about presets.
Update: 8/11/2017 I've been having trouble with this. It seems like things have changed (and npm is on 5.3 now). But what I see is that the heroku-prebuild script is getting run, and then the post-install script is getting run (but I was only trying to install -dev).
So what I have been doing that works is to just run:
heroku config:set NPM_CONFIG_PRODUCTION=false
And just leave it set that way. I'd love a better solution.
you can use this in your build script "build": "npm install --only=dev" should in case you still want to perform more operations e.g transpiling your code with babel you can do something like this "build": "npm install --only=dev && babel src --out-dir dist --copy-files"
To unintall dependencies you need to do these
Update NPM_CONFIG_PRODUCTION
heroku config variable set
NPM_CONFIG_PRODUCTION=false
Add heroku-prebuild:
scripts": {
...
"heroku-prebuild": "npm install"
}
or
scripts": {
...
"heroku-prebuild": "npm install --only=dev"
}
Since 1 March 2018 Heroku installs devDependencies by default, and then prunes them after the build step is done:
By default, Heroku will install all dependencies listed in
package.json under dependencies and devDependencies.
After running the installation and build steps Heroku will strip out
the packages declared under devDependencies before deploying the
application.
Heroku uses the lockfiles, either the package-lock.json or yarn.lock,
to install the expected dependency tree, so be sure to check those
files into git to ensure the same dependency versions across
environments.
Link
I found this highly confusing. Even though Heroku says that their default since 2018 is to install all dependencies, they also set the env var NODE_ENV=production by default. This is good because it causes/allows for pruning, but it is bad because it means NPM will not install devDependencies.
To avoid this without messing with environment variables and their possible side effects, we can append --production=false to npm and it will install dependencies and devDependencies.
In our case, in package.json in scripts we have a line:
"install": "npm i --prefix ... --production=false"
My answer similar to others above with the additional references that seem to explain why it's not actually working by default like Heroku suggests.
I have developed a node.js npm module, developing under Windows. Today I wrote some Mocha tests. After many struggles, it seemed that for npm test to work, package.json had to look like this: (there may be other options???)
"scripts": { "test": "node node_modules/mocha/bin/mocha" }
instead of what's in all the Unix based books,
"scripts": { "test": "./node_modules/.bin/mocha" }
How can I set package.json up to work on both Windows and Unix? I'm assuming that Travis-CI runs Unix, so, should I link the build to that, it will blow up with the Windows version.
I found a two year old thread where somebody requested a feature for exactly this. That thread seemed to die out. This SO question seems to be close, but it isn't exactly what I want and, frankly, I can't understand the answer. :-( Can anybody clarify?
For the time being, I am going
"scripts": {
"test": "node node_modules/mocha/bin/mocha",
"testOnUnixUseThis" : "./node_modules/.bin/mocha (I think)",
"testOnWindowsUseThis" : "node node_modules/mocha/bin/mocha"
},
Unfortunately, you cant go npm test testOnWindowsUseThis or npm testOnWindowsUseThis. And it doesn't fix the Travis-CI issue. But at least a person who downloads the module can (hopefully) see what is going on.
Any better ideas? Am I the only person still developing under Windows??? :-)
I've always been able to npm install -g mocha or npm install mocha and then just add
"scripts": {
"test": "mocha spec"
}
to package.json. That may or may not work in EVERY environment. I know, for instance, with lineman, you have to use bin/mocha. Also, if you don't find a way around this, set your test script up for Unix and then add a second script called "wintest" or something that does whatever you need it to do in Windows. You can name your scripts whatever you want. The default ones (test, start, etc.) can be used with npm [command]; any non-standard ones (like wintest) can be used with npm run-script [command], and they will still work.
A little back story on how/why this works:
When you install a module globally, it's available on PATH (or whatever the windows equivalent is). When you install a project dependency, if that module has any binaries, those are symlinked to node_modules/.bin and when you run npm run [some-command], npm helpfully adds node_modules/.bin to PATH for that command. So when mocha is installed globally "test": "mocha spec" uses your globally installed mocha to run tests. When it's a project dependency, it uses the one in node_modules/.bin. The one gotcha I've found with this is that npm adds node_modules/.bin to the front of PATH, so local binaries will always take precedence over global ones. Almost all of the time, this is what you want, but it's worth knowing that that's how it works (I recently had a bug related to this).
EDIT:
Not sure at what point in npm history this changed, but npm run <script-name> now works (don't need to do npm run-script <script-name> anymore). Possibly run-script still works as well. I'd expect it to, but I haven't tried it.
How can I set package.json up to work on both Windows and Unix?
If you
use Windows
dislike -g global install
...this is a working solution
"scripts": {
"test": "node node_modules/mocha/bin/mocha.js"
},
Notes:
putting node in front shouldn't harm, and can help on Windows (.js extension is not necessarily registered to the nodejus executable, unless you set it so. Could open a text editor, an IDE or (worse) windows scripting host, Internet Explorer…)
Adressing the script directly saves you from needing a global install. (Not judging if this is a good practice)
forward slashes help running under linux (obviously) and do work under windows (in this scenario. Also avoids a windows pitfall: backslashes if used, would need to be doubled – since they are interpreted as escaping the following letter if used solitary).
Don't use global solution, I suggest you follow what the Mocha guys say:
"scripts": {
"test": "node_modules/.bin/mocha -w"
},
Use npm i mocha --save-dev
This will save the module as a development dependency and npm will automatically set up the executables to be used within the scripts object. If you want to use the executables outside of the scripts defined in package.json, you can install it globally as well, although note that you may end up with different versions of the package.
If you only install it globally, other people won't be happy if they try to run your tests (with the standard npm test)
The new way with latest npm versions after 6.x, you needn't install mocha with global mode any more.
"scripts": { "test": "npx mocha" }
npx is installed automatically with new npm installation. It will search
mocha from node_modules/.bin or $PATH
reference: https://www.npmjs.com/package/npx
I'm trying to automate building of my project on a TeamCity server. I'm using grunt to define and configure my tasks. This works fine locally. Yet, I am having problems getting TeamCity (running on Windows Server 2008) to recognize grunt as a executable, the build will fail when grunt is called as it is not available.
I do have grunt-cli installed on the server and can execute it when I login via ssh (The build script also succeeds when I trigger it that way).
I'm running npm install before I call grunt and also tried to force install grunt-cli using a preinstall instruction in my package.json like:
{
"name": "someName",
"version": "0.0.1",
"private": true,
"scripts" : {
"preinstall" : "npm install grunt-cli -g"
},
"devDependencies": {
"grunt": "~0.4.1",
"grunt-contrib-jshint": "~0.6.3",
"grunt-contrib-less": "~0.8.1",
"grunt-contrib-watch": "~0.5.3",
"grunt-contrib-requirejs": "~0.4.1",
"grunt-strip": "~0.2.1",
"grunt-bump": "0.0.11"
}
}
I can see npm installing grunt-cli, yet grunt is not available in the next step.
I also tried wrapping that into a bat file or using multiple build steps for dependency installing and running the grunt task.
Does anyone have any input on this?
I had the same problem when trying to get our TFS Build agents to run grunt-cli. In the end I just changed my build process to use the full path to the grunt-cli executable.
So I changed from using this:
grunt deploy
to using this:
"C:\Users\tfsservice\AppData\Roaming\npm\grunt.cmd" deploy
I know this is just a workaround and not a true fix, but it should be good enough to get you going. I hope this helps.
-- Update --
I was able to get it to work properly by simply adding "C:\Users\tfsservice\AppData\Roaming\npm" (where the grunt.cmd file is found) to my system path, and then rebooting my build server. The reboot was required since tfsservice is both a user and a running service; simply restarting the service may be enough, but I didn't test that.
After doing this grunt deploy worked in our builds as expected.
You are running Teamcity agent on Widnows Server?
There is plugin for Node.js/Grunt for Teamcity: https://github.com/jonnyzzz/TeamCity.Node
As far as I've used it had no issue running grunt with Teamcity.