Cucumber.js is supplying a command-line "binary" which is a simple .js file containing a shebang instruction:
#!/usr/bin/env node
var Cucumber = require('../lib/cucumber');
// ...
The binary is specified in package.json with the "bin" configuration key:
{ "name" : "cucumber"
, "description" : "The official JavaScript implementation of Cucumber."
// ...
, "bin": { "cucumber.js": "./bin/cucumber.js" }
// ...
This all works well on POSIX systems. Someone reported an issue when running Cucumber.js on Windows.
Basically, the .js file seems to be executed through the JScript interpreter of Windows (not Node.js) and it throws a syntax error because of the shebang instruction.
My question is: what is the recommended way of setting up a "binary" script that works on both UNIX and Windows systems?
Thanks.
Windows ignores the shebang line #!/usr/bin/env node and will execute it according to the .js file association. Be explicit about calling your script with node
node hello.js
ps. Pedantry: shebangs aren't in the POSIX standard but they are supported by most *nix system.
If you package your project for Npm, use the 'bin' field in package.json. Then on Windows, Npm will install a .cmd wrapper along side your script so users can execute it from the command-line
hello
For npm to create the shim right, the script must have the shebang line #!/usr/bin/env node
your "bin" should be "cucumber" npm will create a "cucumber" or "cucumber.cmd" file pointing to "node %SCRIPTNAME%". the former being for posix environments, the latter being for windows use... If you want the "js" to be part of the executable name... you should use a hyphon instead... "cucumber-js" ... Having a .js file will come before the .js.cmd in your case causing the WScript interpreter to run it as a JScript file, not a node script.
I would suggest looking at coffee-script's package.json for a good example.
{
"name": "coffee-script",
"description": "Unfancy JavaScript",
"keywords": ["javascript", "language", "coffeescript", "compiler"],
"author": "Jeremy Ashkenas",
"version": "1.4.0",
"licenses": [{
"type": "MIT",
"url": "https://raw.github.com/jashkenas/coffee-script/master/LICENSE"
}],
"engines": {
"node": ">=0.4.0"
},
"directories" : {
"lib" : "./lib/coffee-script"
},
"main" : "./lib/coffee-script/coffee-script",
"bin": {
"coffee": "./bin/coffee",
"cake": "./bin/cake"
},
"scripts": {
"test": "node ./bin/cake test"
},
"homepage": "http://coffeescript.org",
"bugs": "https://github.com/jashkenas/coffee-script/issues",
"repository": {
"type": "git",
"url": "git://github.com/jashkenas/coffee-script.git"
},
"devDependencies": {
"uglify-js": ">=1.0.0",
"jison": ">=0.2.0"
}
}
I managed to figure out a solution to a similar issue.
My original plan was to have only one large .js file, for both the API and CLI (the reason is because I didn't know how to share variables between two files at the time). And when everything was built, I tried to add the #!/usr/bin/env node shebang to my file. However that didn't stop Windows Script Host from giving an error.
What I ended up doing was coming up with an idea of a "variable bridge" that allowed variables to be read and set using getVar and setVar. This made me have to extract the CLI code from the API code and add some imports to the variable bridge.
In the CLI file, I added the shebang, and modified the package.json of my project to have:
{
...
"main": "./bin/api.js",
"bin": {
"validator": "./bin/cli.js"
}
...
}
Here are a few small notes that I think might help if Windows Script Host is still giving an error (I applied all of them so I'm not sure which one helped):
Using only LF line endings seemed to help.
It seems that ./bin is the preferred directory for compiled files. I did try ./dist but it didn't work for me.
An empty line after the shebang may be needed:
// cli.js
#!/usr/bin/env node
// code...
Using the same name for main and bin in package.json seemed to be an issue for me.
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"
}
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
When a build a conda environment like this
conda create --prefix env python=3.6.5
Some absolute paths appear in some json files in the conda-meta folder. How can I avoid it? I just want to use relative paths here or I just want to hide them completely. Is there a way to achieve this? Are they mandatory? See extracted_package_dir, source or package_tarball_full_path attributes:
{
"arch": "x86_64",
"build": "py36_0",
"build_number": 0,
"channel": "https://repo.anaconda.com/pkgs/main/win-64",
"constrains": [],
"depends": [
"python >=3.6,<3.7.0a0"
],
"extracted_package_dir": "C:\\Users\\UserName\\AppData\\Local\\conda\\conda\\pkgs\\certifi-2019.3.9-py36_0",
"features": "",
"files": [
"Lib/site-packages/certifi-2019.03.09-py3.6.egg-info",
"Lib/site-packages/certifi/__init__.py",
"Lib/site-packages/certifi/__main__.py",
"Lib/site-packages/certifi/__pycache__/__init__.cpython-36.pyc",
"Lib/site-packages/certifi/__pycache__/__main__.cpython-36.pyc",
"Lib/site-packages/certifi/__pycache__/core.cpython-36.pyc",
"Lib/site-packages/certifi/cacert.pem",
"Lib/site-packages/certifi/core.py"
],
"fn": "certifi-2019.3.9-py36_0.tar.bz2",
"license": "ISC",
"link": {
"source": "C:\\Users\\UserName\\AppData\\Local\\conda\\conda\\pkgs\\certifi-2019.3.9-py36_0",
"type": 1
},
"md5": "e1faa30cf88c0cd141dfe71e70a9597a",
"name": "certifi",
"package_tarball_full_path": "C:\\Users\\UserName\\AppData\\Local\\conda\\conda\\pkgs\\certifi-2019.3.9-py36_0.tar.bz2",
"paths_data": {
"paths": [
[...]
If I remove the whole folder the environment become useless and I cannot activate it anymore in order to install, update or remove new packages.
I want to do this to encapsulate the environment in one application and I do not want to have my original absolute paths in the computer of the final user.
My Use Case
I am developing an electron app that uses a tornado server (that uses python)
Currently I am using electron-builder to add the environment to the installer and works pretty well, but one drawback is the conda-meta folder I commented above. What I do now is to remove it manually when I want to make an installer.
That will probably break conda. It's not written to treat those as relative paths. If you told us more about your use case, maybe we could help. Are you trying to redistribute an installed environment? Have you see the "constructor" or "conda-pack" projects?
Finally the best solution I found was to ignore the folder when creating the final installer with electron-builder.
So I have applied the directive extraResources to add the conda environment except the folder conda-meta. And I have added the filter "!conda-meta${/*}", the meaning is explained here
Remember that !doNotCopyMe/**/* would match the files in the doNotCopyMe directory, but not the directory itself, so the empty directory would be created. Solution — use macro ${/*}, e.g. !doNotCopyMe${/*}.
The result in the package.json file:
"extraResources": [
{
"from": "../env",
"to": "env",
"filter": [
"**/*",
"!*.pyc",
"!conda-meta${/*}"
]
}
],
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.
For example, there is package for less LessToCss. As for Sass(or SCSS) I don't know what i should do. Ruby and sublime package Sass are installed.
You have to alter the PATH variable at the end of PATH string in the Environment Variables: Desktop - Properties - Environment Variables. It for win vista/7 users. Detail for 2000/XP here Sass compiler not working in sublime text 3
One way is to download a SASS build compiler from here: SASS Compiler
This is automatic Sublime package that simply builds your file at the place.
However since they released the new version, there seem to be multiple settings on this package - you could try to mess with that a bit and see what it can do nowdays.
Second way is to write your own Build command in Sublime. You do this by going to "Tools>Build System>New Build System..."
{
"cmd": ["sass", "--update", "$file:${project_path}/Project/Web/css/${file_base_name}.css", "--stop-on-error", "--style", "compressed", "--no-cache", "--sourcemap=none"],
"selector": "source.sass, source.scss",
"line_regex": "Line ([0-9]+):",
"osx":
{
"path": "/usr/local/bin:$PATH"
},
"windows":
{
"shell": "true"
}
}
Explanation: I use a folder structure as the following: Project/Web/CSS - If you have the Sublime Project FILE at the same level as Project FOLDER, then this will automatically build your Sass file (placed ANYWHERE in the project file) in your Web/CSS folder. Of course you can change this as you see fitting.
here is 100% solution, as i also using. Actually i am using in mac so, i am not sure about windows because i wouldn't try yet in windows but i think it will works in window's too.
so here is the build;
copy this from starting brackets and paste it into build and then save with any name like (Build to CSS),"
{
"cmd": ["sass", "--update", "$file:${file_path}/../css/${file_base_name}.css", "--stop-on-error", "--no-cache"],
"osx":
{
"path": "/user/local/bin:$PATH"
},
"windows":
{
"shell": true
}
}
If it's working then please comment.
Thanks