Normally when pointing node to a folder, if there is an index.js file there, we don't need to specify it.
I installed an NPM dependency that I am working on, npm install --save-dev suman.
Suman has an index.js file at the root of its NPM project.
In my NPM scripts for a project that depends on suman, I have this:
"scripts": {
"test": "node node_modules/suman/index.js --rnr test"
}
The above works!
But this doesn't work:
"scripts": {
"test": "node node_modules/suman --rnr test"
}
Why is this?
Perhaps the answer is obvious - the require function in node is capable of such behavior, but node itself is not.
Since the library has a bin in its package.json, you don't need to explicitly provide the path to it. Just run node suman --rnr test and npm will take care of using the correct file.
When you install a dependency with a binary in your node project, npm creates a symlink to that file in ./node_modules/.bin and uses those when running npm scripts.
You need to add the correct path:
"scripts": {
"test": "node ./node_modules/suman --rnr test"
}
Notice the ./
Update:
After thinking about this a bit more, It may not be this easy. But take a look at this link: https://docs.npmjs.com/misc/scripts - #elssar seems to be on the right track.
Sorry that I can't include my thoughts simply as a comment rather than as an answer but I don't yet have enough reputation points to comment. However, perhaps the following is relevant:
If, in your problem, the node command finds the appropriate index.js the same way as is shown in the node documentation for modules, then the documented look-up routine will find a different index.js before finding the one that (I think) you want. Specifically, before trying node_modules/suman/index.js (which is the one you want), node will look to see if the "main" field in node_modules/suman/package.json exists. In suman, it does, and it references lib/index.js (i.e. node_modules/suman/lib/index.js) which is different than the one you want. Is that relevant?
UPDATE: Just to clarify my answer with more generic language...
Your original question is a valid one because, in the absence of any other complications, if dir/index.js exists, then both of the following
node dir/index.js ...
node dir ...
should refer to the same (default) file, i.e. dir/index.js. Thus it is reasonable to be confused when those two commands give different results. The explanation is that there IS a complication: the dir/package.json file effectively redirects node dir ... to use a non-default file. This is because the "main" property refers to dir/some/other/file.js. The rules of precedence specify that, if only a directory name is used, this other file will be used before the default. Thus, you are forced to continue to use the longer and more explicit "working" command from your question.
Related
I'm pretty sure its my folders filepath for my compile Sass script, but I've been at this one a few hours now, so I'm hoping you can help... (maybe there's a setup setting IDK about?...
Two similar projects - 1 Vanilla, 1 React.
1. On both I have node, NPM and node-sass installed; via: npm i --save-dev node-sass
2. I've got livesass compiler going. On vanilla it works as expected. On the React project live-sass-compiler keeps on crashing (it is working long enough for me to test it though) and when i run in the terminal: npm run compile:sass the terminal turns into a node, never compiles, and also seems to get stuck in this state.
Please help!
NOW FOR THE DIFFERENCES:
==========Filepaths==========
(Filepath is indicated by "./", multiple files indicated by array syntax.
Vanilla (root):
index.html (stylesheet href="./STYLES/SCSS/index.css")
index.js
./STYLES/ [index.css, index.css.map, index.scss]
package.json (script: "compile:sass": "node-sass STYLES/SCSS/index.scss STYLES/output.css -w")
Works great!
REACT (root):
./public/index.html (stylesheet href="../src/STYLES/CSS/index.css")
./src/index.js
.src/STYLES/ [index.scss, (desired css output)]
package.json (script: "compile:sass": "node-sass src/STYLES/index.scss src/STYLES/CSS/index.css -w")
in both of them, inside the node-modules folder, I have installed:
"devDependencies": {"node-sass": "^7.0.1"}
Hey, I figured it out! - I got rid of live-sass-compiler (it's depreciated). - I also removed the "script: "compile:sass": "node-s..."" as it's no longer required. Compilation will happen natively every time you save the file.
TO USE WITH REACT:
Terminal:
npm install -D sass
sass —watch scss:css
1. add an .env file to the root. Inside type: “SASS_PATH=src/STYLES/SCSS”
(this allowed relative paths to be ignored on previous versions. I haven't gotten this to work but everything else seems to work. It may be depreciated... IDK.)
2. include the filepath import to the JS page you’d like the CSS to live under:
(example (for APP-WIDE Changes): index.js: import './STYLES/index.scss’ //imports to the app component
3. to import another file from index.scss:
Within the index.scss file:
#use './SCSS/_unorganized.scss'; // ("#import" will soon be depreciated, instead use #use)
Hope this saves someone else some time!
I run Cypress from the command line as:
npx cypress open --env team=XXXX --config-file my_file.json
where my_file.json is my config file and contains:
env: {
"team": ""
}
I know that when I pass a value via CLI with no space in it the Cypress runner will show that value in the configuration tab. How do I pass a value such as to team like:
--env team=XXXX XXXX
I have tried using "" and '' around the argument already and they have not worked. Thank you.
From the documentation, it says "Pass several variables using commas and no spaces". So, off the bat, it sounds like what you're trying to do isn't possible. However, it may be worth a shot to try a different method. In particular, from this screenshot from the link I provided,
you can see that the last approach passes a JSON object. Perhaps, if for some reason Cypress parses this JSON object differently, you can try
cypress run --env team='{"key": "XXXX XXXX"}'
Alternatively, you could also have multiple Cypress configuration files, each with the relevant team value. However, if you have multiple team values, this simple approach doesn't scale particularly well.
I'm going to leave this comment here, in case someone else is looking for a solution.
this is what I did, and it worked for me.
in the terminal i'm doing:
npm run chat_true -- --env type="dev test"
note the "--" before --env
that's the only way I found to overwrite my env value, set in the package.json file like:
"chat_true": "cypress open --env type=live",
I don't need a space in the middle of the value, so I'm not using a quote surrounding the value, but I just tried it and it worked.
I'm three months late :D
I made a React app using Create-React-App. I have a testing script in my React app's package.json like this:
"test": "node -r #babel/register -r #babel/polyfill **/*.test.js | tap-color",
This catches and executes the files in src/ like src/App.test.js, but not header.test.js in src/layout/header/header.test.js. And what if I add even more layers of folders? Is there a regex that will catch all folders in src/ and their subfolders no matter how nested with a file ending of .test.js?
Edit: I found this question on StackOverflow. According to that answer you would have to write:
"test": "node -r #babel/register -r #babel/polyfill 'src/**/*.test.js' | tap-color",
which unfortunately matches nothing for me. I'm on Mac.
The question you refer to is not especially useful for your case. My answer there works because Mocha has been designed to pass the patterns you give to it to the glob library for interpretation. So when you do mocha 'src/app/**/*.tests.js' the quotes prevent the shell from interpreting the pattern, Mocha gets src/app/**/*.tests.js as the first pattern given to it, which it gives to glob to get a list of files to actually run. Your case is different at least one crucial way: glob is not involved so there is nothing that can correctly interpret **.
Your first attempt is consistent with what happens when you are using a shell that does not understand **. It is interpreted exactly the same as *. So the shell interprets **/*.test.js as */*.test.js, expands this pattern and passes the result to node.
In your second attempt, you quote the pattern but that does not help you because node does not do pattern interpretation. It tries to load a file at path src/**/*.test.js, interpreted literally. This is not what you want.
I'm not sure what the compatibility implication with Windows are, but you could replace 'src/**/*.test.js' with $(find src -type f -name '*.test.js'). (See the man page for details.) At run-time, the shell will replace this with the result of the find command.
Or for greater simplicity, and less risk of platform issues creeping up, you could use babel-tap like this:
babel-tap 'src/**/*.test.js' | tap-color
If you use babel-tap, there's actually no need for using find because internally babel-tap calls on facilities that use the glob library to interpret the file names passed to it.
I've focused on the file pattern issue but I'm not seeing how what you're trying to do would work, even without the pattern issue. Consider this command, and assume that the files exist:
node -r #babel/register -r #babel/polyfill src/a.test.js src/b.test.js
This is not telling Node to run src/a.test.js and src/b.test.js. Rather, it tells node "run the script src/a.test.js and pass to it the parameter src/b.test.js". I've not used tap very much but I don't recall it working this way. Using babel-tap like I show above also avoids the problem here.
When using #vue/cli-plugin-unit-jest, I am receiving coverage reports each time I run my unit tests, regardless of whether I have the --coverage flag in the execution line or not. I do not want to receive coverage reports on all of my untested files. When searching for an answer online, there are numerous questions about how to turn that feature on, not turn it off. I can't find it in the documentation either.
How do you disable the Coverage on Untested Files feature in Jest?
Disabling coverage similar to enabling it, just prefix the pattern with an ! like so:
{
"collectCoverageFrom": [
"**/*.{js,jsx}",
"!**/node_modules/**",
"!**/folder-with-untested-files/**"
]
}
Or disable coverage all together with "collectCoverage": false.
If that does not work, then you have this params overridden somewhere in your code.
"collectCoverage": false
in jest.config.js
You can also suppress coverage from the command line. The package I'm working with provides a test script, and I was able to pass the collectCoverage option in as a flag. The relative path here works because my test runner is called by npm and that should set the working directory to the root of my project:
npm run test -- path/to/your.spec.js --collectCoverage=false
And the other way around, you can specific a single file to collect coverage from. It'll override any broad-ranging glob you may have already defined in your project's test config files. One reminder, you collect coverage from your source file, not your spec file. And one other reminder, you can list pretty much any file you want in that coverage option, so make sure you get it right:
npm run test -- path/to/your.spec.js --collectCoverageFrom=path/to/your/source/file.js
Package.json
testw": "jest --watch --collectCoverage=false"
watches the test files for change
npm command
npm run testw Yourfilename.js
"collectCoverage": false
in package.json, will disable coverage, collection, As mentioned by #Herman you can also put ! before file pattern in value of property collectCoverageFrom in package.json
In my case, in package.json I have this statement collectCoverage:false and still I was getting errors. Then I realized I also have collectCoverageFrom line and I removed it since I did not need it. After removing the below line it worked as a charm.
"collectCoverageFrom": [
...,
...
]
I'm converting an existing project from js to typescript. I want to be able to set noEmit = true on one folder but have the other folder have noEmit = false.
The reason is that I have my client(angular) code set up through webpack and do not need typescript to generate the javascript for me. While the server (Node/express) still needs to be generated into javascript.
I've tried a few different combinations but haven't seem to find the right way to do it.
My only solution that I've been able to get to work is having two tsconfig.json and running a command like tsc -p src\server\tsconfig && tsc -p src\client\tsconfig
I realize that this is not a good solution, but I have not gotten a single tsconfig to work nor having a base tsconfig.
Here is the folder structure..
|-Src
|--/client
|--/server
Is there a way to achieve this using a single tsc command? Or is there a better way I should be formatting the project? Thanks!!
I don't think there's another solution besides having multiple tsconfig.json files like you're already doing, as per this answer and this comment.
You can make this a little more streamlined by having a tsconfig.json for compilation and a separate tsconfig-build.json that you use in your package.json for building, i.e.:
// package.json
{
"scripts": {
"build": "tsc -p tsconfig-build.json"
},
// ...
}
With this setup (assuming the default tsconfig.json is in your root), running tsc from the command line will use the default tsconfig.json, but running npm run build will use tsconfig-build.json. You can also have one tsconfig extend from another, so if you have a lot of options in common, you could add a tsconfig-base.json that both configs extend from.
You can probably achieve what you want with the exclude property in your tsconfig.json file.
Check the documentation
for the exclude property