I want to breakpoint to webpack Source Code in Intellij IDEA 2016.2 for Mac.
it tips:
To debug "build-distributor" script, make sure $NODE_DEBUG_OPTION string is specified as the first argument for node command you'd like to debug.
For example:
{ "start": "node $NODE_DEBUG_OPTION server.js" }
but,where is add this code when debugging webpack?
Today I had the same problem and found the place where to put the NODE_DEBUG_OPTION. You have to change or create a new npm script which points to the javascript file. For example, I wanted to set breakpoints in an webpack plugin so my original npm script looked like
"scripts": {
"build": "webpack"
},
my new script with the NODE_DEBUG_OPTION looks like
"scripts": {
"build": "node %NODE_DEBUG_OPTION% ./node_modules/webpack/bin/webpack.js"
},
I'm working on an Windows Machine. Thats the reason why my NODE_DEBUG_OPTION is between two "%" and yours have an "$" in front of.
Related
I use package.json variables like this in NPM scripts:
// package.json
{
"version": "0.12.1",
"scripts": {
"get-version": "echo %npm_package_version%"
}
}
npm run get-version currently echoes %npm_package_version% instead of 0.12.1. In the past, the scripts worked without any problems. Suddenly only the variable name comes back. With multiple repositories. I run Windows 10 2004 and NodeJS v15.4.0.
Was there a change for NPM scripts in Node.js 15? Is it a bug or a feature?
UPDATE: Failure to expand environment variables on Windows appears to be a recent high-priority known bug in the npm CLI.
Because this is npm#7 specific, until a fix is released, you can downgrade to npm#6.
ORIGINAL ANSWER:
The easiest solution for the specific case in this question is to use node.
"get-version": "node -p process.env.npm_package_version"
This will work on every platform that Node.js supports.
If you need a more general solution and don't want to rewrite a bunch of scripts to use node, you can try cross-var as mentioned by #RobC in the comments.
As for the source of the problem, perhaps you are running under the Windows bash shell, in which case you can use this:
"get-version": "echo $npm_package_version"
That won't work for non-bash Windows environments though.
I found simple hack which is working perfect in my case,
Specifically in your use case
// package.json
{
"version": "0.12.1",
"scripts": {
"get-version": "node -e \"console.log(process.env.npm_package_version)\""
}
}
Usage
npm run get-version
However you want to pass arguments.
// package.json
{
"scripts": {
"get-argument": "node -e \"console.log('your argument:', process.argv[1] )\"",
}
}
Test example
npm run get-argument hello_world
Default values are a great way to handle undefined values. We use a predefined value instead. Inside our NPM script we can achieve that by using the following syntax;
{
"version": "0.12.1",
"scripts": {
"get-version": "echo ${npm_package_version:0.99}"
}
}
And of course, running npm from a bash prompt might help. I guess running from a Cmd/Powershell "could work" but I would be careful about that.
FYI - A related change in Version 7 if you are using the Package config variables:
The variable name changed from npm_package_config_customFooVar in V6 to npm_config_customFooVar in V7
Delineate these appropriate (as below) to the environment (Windows bash linux etc) being used. or Use lib like cross-var.
Package.json
{
"config": {
"customFooVar": "bar",
"env": "development"
},
"scripts": {
"get-var": "echo using env1 $npm_config_customFooVar OR env2 %npm_config_customFooVar%"
"build": "npm config set myAppName:env"
"postbuild": "cross-var ng build --configuration=$npm_config_env && cross-var node myOtherBuildSript.js $npm_config_env"
}
}
e.g. npm-cli call (note space after --) as this is passed to the script. Not to npm itself.
npm run build -- production
pass args from package.json to cli
echo %npm_package_version%
This solution allowed me to use the npm_package_version variable in both Windows and Unix:
Install run-script-os as a dev dependency. Then in your package.json the variable can be used:
"scripts": {
...
"postversion": "yarn postversion-wrapper",
"postversion-wrapper": "run-script-os",
"postversion-wrapper:windows": "echo %npm_package_version%",
"postversion-wrapper:nix": "echo $npm_package_version"
}
I was trying to update our production project which holds 500+ modules and we certainly need this tool to make it work because manually doing so would be a nightmare. I've been the whole afternoon trying to make it work even copying and pasting your import example and haven't manage to do so.
Our imports are like following in the whole project:
import {
NzTableModule,
NzCheckboxModule,
NzInputModule,
NzFormModule,
NzSelectModule,
NzDrawerModule,
NzDividerModule,
NzToolTipModule,
NzDatePickerModule,
} from 'ng-zorro-antd';
I'm using the following config:
{
"rulesDirectory": [
"nz-tslint-rules"
],
"rules": {
"nz-secondary-entry-imports": true
}
}
package.json:
"ng-zorro-antd": "^9.3.0",
"typescript": "~3.8.3",
"nz-tslint-rules": "^0.901.2",
"#angular/core": "~9.1.12",
I'm executing the following command from the app root:
"tslint --project ."
I've managed to be sure about the script execution with a console log in the nzSecondaryEntryImportsRule.js file
Also I've notice that:
tsutils.isImportDeclaration(node)
Always returns false therefore it continues to the next iteration in the for loop
I'd appreciate any help on this.
I guess because the global version is too low.
here are three solutions:
upgrade your global tslint
npm install tslint -g
add the command to the scripts in package.json, and then use npm run lint:fix
{
"scripts": {
"lint:fix": "tslint --project tsconfig.json --fix"
}
}
run from node_modules/.bin/tslint
node_modules/.bin/tslint --project tsconfig.json --fix
Running Cypress and came across using xpath in Cypress and I am trying the following code in .js file.
/// <reference types = "cypress" />
describe ("Test Contact us form",()=>{
it("Should be able to submit the form", ()=>{
cy.visit('some url');
cy.xpath('//a[contains (#href, "contact")]').click();
});
})
This is how my xpath node_modules directory path looks like
\Projects\node_modules\xpath
Here is my index.js
// Alternatively you can use CommonJS syntax:
// require('./commands')
require('xpath')
Here is my package.json
{
"name": "projects",
"version": "1.0.0",
"description": "test",
"main": "index.js",
"scripts": {
"test": "Thisistest"
},
"author": "",
"license": "ISC",
"devDependencies": {
"cypress": "^5.2.0",
"xpath": "0.0.29"
}
}
Here is a snippet of the package-lock.json
"xpath": {
"version": "0.0.29",
"resolved": "https://registry.npmjs.org/xpath/-/xpath-0.0.29.tgz",
"integrity": "some key",
"dev": true
},
After running the test, I am getting the following compilation error.
Its a TypeError.
cy.xpath is not a function
Seems to be a small config thing. However, followed the exact steps as given on https://github.com/cypress-io/cypress-xpath#readme
I removed and re-setup cypress and xpath again using npm through git bash and it worked.
Previously, I had setup using node.js command prompt. After installing xpath using same npm command, xpath was successfully downloaded, however, the directory name inside node_modules was just xpath instead of cypress-xpath. Now, even though I had require('xpath') under the index.json file, it was still unable to detect xpath.
[Updated for Cypress Ver- 10.9.0 in year 2022]
Use link below to install: cypress-xpath plugin
https://www.npmjs.com/package/cypress-xpath
Step 1: Install XPath Plugin using below command
npm install cypress-xpath
Step 2 Add this line to e2e.js in support folder
require('cypress-xpath');
Step 3 Add your xpath in cy.xpath method like below:
cy.xpath("//input[#name='userName']").should("be.visible");
Please make sure to check that you're getting code intellisense like this (refer image attached), once successful installation of the cypress-xpath plugin.
I had faced the same issue.
then I changed the reference types from cypress to cypress-xpath as follows
///reference types = 'cypress-xpath'
and the problem is resolved.
This might be helpful to you.
I downloaded cypress-xpath and updated the config file with requires('cypress-xpath) and then tried and it worked
I have my project setup as follows, within my package.json I have the follow:
"scripts": {
"test": "echo \"Error: no test specified\" && exit 1",
"dev": "parcel ./public/index.html --open",
"build": "parcel build ./public/index.html NODE_ENV=production --no-source-maps --public-url ./public --out-dir ./dist",
"lint": "eslint --ext .js,.vue src --fix"
},
I can start my project by running: npm run:dev which starts as follows:
To debug the "dev" script, make sure the $NODE_DEBUG_OPTION string is specified as the first argument for the node command you'd like to debug.
For example:
"scripts": {
"start": "node $NODE_DEBUG_OPTION server.js"
}
> impcentral#1.0.0 dev /Users/william/imp/src/impCentral
> parcel ./public/index.html --open
Server running at http://localhost:63188 - configured port 1234 could not be used.
As you can tell it does not stop at my break points within WebStorm. I've tried passing in the $NODE_DEBUG_OPTION within the package.json but to no avail.
Any ideas folks, open to trying this in Visual Studio Code too.
You don't need running your NPM configuration in debugger unless you need debugging parcel itself. As your application, served by parcel, is run in browser, you have to use JavaScript Debug run configuration to debug it.
start your app by running npm run dev (either in WebStorm or in terminal)
create a JavaScript Debug run configuration with your server URL (http://localhost:1234, or http://localhost:63188 in your case):
select this configuration and press Debug
I am trying to have npm watch for file changes in my client side code. I can have it work from the command line ok but I'd really like it to work from Visual Studio task runner.
my package.json looks something like this:
...
"watch": {
"compile": {
"patterns": [
"wwwroot"
],
"extensions": "ts"
}
},
"scripts": {
"prebuild": "copyfiles -f ./node_modules/d3/build/*.js ./wwwroot/lib/d3",
"compile": "tsc && browserify ./wwwroot/app/app.js -o ./wwwroot/bundle.js",
"build": "npm run compile",
"watch": "npm-watch"
},
...
So running npm run build then npm run watch from the command line has everything running as expected.
When I use the Task Runner however to bind my watch script to the After Build event like this:
it never 'exits' and, as such, the build never completes* and Visual Studio waits for me to kill the task before the application runs. Is there a way to have the script run in the background or some kind of 'detached' mode to enable Visual Studio to complete the build and run the application?
I tried using different watch tools but can't find any such option in any of them.
*Actually, I guess the build itself probably DOES complete but VisualStudio never runs the app and just hangs waiting on the script exiting.
Change the watch Bindings to Project Open. Then it will start watching after the project is opened.