I am following step 1 of this tutorial
I have the following folder structure:
├── lib
│ ├── json
│ │ ├── messages.json
│ │ └── testMessages.json
│ └── model.js
├── test
│ └── model.test.js
└── package.json
My package.json has the following to run the mocha tests
“test”: “mocha -r esm ./test/* —exit”,
But I get the following error
> backend#1.0.0 test /Users/lee33ya/Desktop/mern-app/backend
> mocha -r esm ./test/* --exit
Error: No test files found: "./test/*"
npm ERR! Test failed. See above for more details.
What am I doing wrong and what can I do to resolve my tests not running?
My github
Found two issues
Your package.json file is misplaced. Place it with ".gitignore" file. And run "npm install"
"chai" is required. Do "npm install chai"
while doing a mocha test these things you should follow
first npm init this initializes the package.json file
Then add the following inside the package.json file
"script": {"test" : "mocha"} (this should be inside the main { })
then install mocha as a dependency by doing npm install mocha -D
then make a test folder in the main file and put the .js file you want to test
then run npm test
if i didn't explain correctly i am sorry and this is my first answer so :)
here is a very good article on mocha if you want to see
https://blog.logrocket.com/a-quick-and-complete-guide-to-mocha-testing-d0e0ea09f09d/
Related
I have the following project structure, outside of GOPATH.
. // Project root
├── Dockerfile
├── .env
├── README.md
└── src
├── main.go
├── go.mod
├── go.sum
├── internal
│ ├── somepackage
│ │ ├── main.go
│ │ └── types.go
│ ├── someother
│ │ ├── main.go
│ │ ├── oauth.go
│ │ └── types.go
│ └── models
│ └── main.go
└── pkg
├── somepackage
│ └── main.go
└── anotherpackage
└── main.go
I want to run my Go module code located in the src directory.
When I cd into the src directory and go run . or go build . my code, it works perfectly.
When I stand at the root of my project, I am unable to run go run ./src or go build ./src. I get the following error.
src/service.go:8:2: cannot find package "web-service/internal/auth" in any of:
/usr/lib/go/src/web-service/internal/auth (from $GOROOT)
/home/miloertas/Packages/go/src/web-service/internal/auth (from $GOPATH)
src/endpoints.go:3:8: cannot find package "web-service/internal/handlers" in any of:
/usr/lib/go/src/web-service/internal/handlers (from $GOROOT)
/home/miloertas/Packages/go/src/web-service/internal/handlers (from $GOPATH)
It's important that my source code remains in this src directory.
It is equally important that I am able to run and build my code from the root of my project (For example the .env file is located at the root of the repository).
I am therefore looking for a way to run or build my code in the src directory from the root of my project.
I tried moving the go.mod at the root of the project and running and ran go run ./src but this causes issues of its own:
The go command is now unable to locate all the sub-packages in internal and pkg
VSCode is now lost and executing tests is impossible for some reasons (Mainly because all sub-packages are not found).
Since Go 1.18, it's now possible to achieve this with Go workspaces.
Using the following directory structure
parent-dir/
└─ go.work
hello-world/
├─ go.mod
└─ main.go
You can run the hello-world module from the parent-dir using go run hello-world.
go.work
go 1.18
use ./hello-world
go.mod
module hello-world
go 1.18
Note: it is possible, not recommended as pointed out by #Volker
It's important that my source code remains in this src directory. It is equally important that I am able to run and build my code from the root of my project (For example the .env file is located at the root of the repository).
These two requirements are contradictory. You have to let go of one.
Especially the second one is unfounded: Do not use go run, use go build. Make the path to look for the .env file a command line option to your program (Go is not PHP or JavaScript, there simply is no project or source root for the executing binary). Or build the executable somewhere but execute it in you project root.
Note that having a src folder is -- to put it mildly -- uncommon.
I tried moving the go.mod at the root of the project and running and ran go run ./src but this causes issues of its own:
Well, start by not using go run at all, use go build. And then try building the actual main package. All the go tooling works best on packages, not on file system folders. If your module is named playing.hardball/for-unspecific-reasons and package main is in src try go build playing.hardball/for-unspecific-reasons/src.
Takeaways even if this doesn't work out the way you want:
Do not use go run. The reasons are manyfold, it is useful to run single file scripts and a loaded footgun for basically every other use case.
The go tool works on import paths. In simple cases the import path can be inferred from the filesystem.
A compiled executable has no notion of a "project directory", "source", "classpath" or whatever, it is a standalone executable runnable everywhere and completely detached from its sources.
Make all filesystem lookup path a configuration option (cmdline flag or environment variable); provide practical defaults (e.g. ./); use that when running your executable to announce where to find static stuff like .env files, templates, icons, css files, etc.
Here is the directory structure of my project (~/go/src/bitbucket.org/a/b):
├── cmd
│ ├── c
│ │ └── main.go
│ └── d
│ └── main.go
├── config
│ ├── config.go
│ ├── default.json
│ └── development.json
├── go.mod
├── go.sum
├── log
│ └── log.go
├── main.go
I need to compile 2 binaries (one for each module in cmd/).
I have tried running GO111MODULE=on go build ./cmd/c from project root (~/go/src/bitbucket.org/a/b). It silently finishes without doing anything.
I also tried running GO111MODULE=on go build -o test ./cmd/c. It created 29kb test file. When i add execution rights to it and run, it finishes with error:
./test: 2: ./test: Syntax error: newline unexpected
I have tried using go 1.12.5 and go 1.11.10.
Also when i put main.go file from any of the cmd directories to project root directory and build, the compiler builds it just fine (binary file size is ~33mb).
Is it possible to use 2 compiler entry points in a single project?
You can use go install ./... and it will create the executables in $GOPATH/bin directory if you are looking to get the executables
And regarding the multiple compiler entry points, you can. You can build using go build ./cmd/c ./cmd/d . but you cannot get the executables as per the GO Documentation -o can be only used in the case of single package. Instead you can write a makefile to get all the executables with a single make target.
And regarding the error that you are seeing, I would need more information. When I tried to build a sample application, everything works fine. I am not using GO111MODULE flag though.
go build gives me stackoverflow executable
go build -o test ./cmd/c gives me test executable
go build ./cmd/c gives me c executable
For your convenience I uploaded the project to github repo
When trying to run bundle exec jekyll serve on a Windows 10 machine, this error occurs:
jekyll 3.7.4 | Error: File to import not found or unreadable: reset.
Load paths:
C:/Ruby25-x64/lib/ruby/gems/2.5.0/gems/minima-2.5.0/_sass
C:/Ruby25-x64/lib/ruby/gems/2.5.0/gems/minima-2.5.0/_sass on line 6
My directory structure is as follows:
.
├── _config.yml
├── README.md
├── _sass
| ├── _reset.scss
| └── _variables.scss
├── assets
| ├── styles
| | └── design.scss
├── .gitignore
├── Gemfile
├── Gemfile.lock
└── index.md
Please note that this works on my Mac (I just cloned the git repository and tried to serve on Windows).
I've tried adding this to _config.yml but it did not change anything.
sass:
sass_dir: _sass
I switched from "native Windows" to docker to build my Jekyll pages.
Jekyll on Docker Hub.
Create the folder $PWD/vendor/bundle before using docker.
docker run -it --rm \
--volume="$PWD:/srv/jekyll" \
--volume="$PWD/vendor/bundle:/usr/local/bundle" \
jekyll/jekyll \
jekyll build
I am on mac and Installed maven using the brew install maven command. The maven was installed in /usr/local/Cellar/maven/3.3.9 path. Then i edited my ~/.bash_profile file and put the following entries
export M2_HOME="/usr/local/Cellar/maven/3.3.9"
export PATH="$PATH:$M2_HOME/bin"
now when i try mvn -version maven throws the error that
Error: Could not find or load main class org.codehaus.plexus.classworlds.launcher.Launcher
Did i configure it wrong ?
EDIT: Maven folder
$ tree -L 2 $M2_HOME
/usr/local/Cellar/maven/3.3.9
├── INSTALL_RECEIPT.json
├── LICENSE
├── NOTICE
├── README.txt
├── bin
│ ├── mvn
│ ├── mvn.cmd
│ ├── mvnDebug
│ ├── mvnDebug.cmd
│ └── mvnyjp
└── libexec
├── bin
├── boot
├── conf
└── lib
I have also seen as an option:
Create a file ~/.MacOSX/environment.plist with:
{
"M2_HOME" = "/usr/local/Cellar/maven/3.3.9/libexec";
"M2" = "/usr/local/Cellar/maven/3.3.9/libexec/bin";
}
and restart / log back in. This would make tools like IntelliJ also pick it up.
However in my case, I found some other setup script had installed an export for M2_HOME in my .profile which broke the maven install.
I am trying some "cookbook-examples" on the site 'http://tech.pro/tutorial/1190/package-managers-an-introductory-guide-for-the-uninitiated-front-end-developer#front_end_developers'.
You should not have to look there now, but I thought it could be good to share the site.
So far so good, til it comes to the global installing.
When it comes to the point trying to install something globally I get stuck.
What I did so far for testing globally installing some package:
Created test-directory grunttest
Inside that directory:
npm install -g jshint
Output I can see:
npm http GET https://registry.npmjs.org/jshint
npm http 304 https://registry.npmjs.org/jshint
...
npm http 304 https://registry.npmjs.org/string_decoder
C:\Program Files\nodejs\node_modules\npm\jshint -> C:\Program Files\nodejs\node_modules\npm\node_modules\jshinnt
jshint#2.4.4 C:\Program Files\nodejs\node_modules\npm\node_modules\jshint
├── console-browserify#0.1.6
├── exit#0.1.2
├── underscore#1.4.4
├── shelljs#0.1.4
├── minimatch#0.2.14 (sigmund#1.0.0, lru-cache#2.5.0)
├── cli#0.4.5 (glob#3.2.9)
└── htmlparser2#3.3.0 (domelementtype#1.1.1, domutils#1.1.6, domhandler#2.1.0, readable-stream#1.0.26-2)
I just realize the 304, which should be ok, due to just says the resource was not modified since last installation (few minutes before).
Checking if the jshint exists with:
`npm -global list`
Output:
npm#1.4.3 C:\Program Files\nodejs\node_modules\npm
├── abbrev#1.0.4
├── ansi#0.2.1
├─...
├──
├── graceful-fs#2.0.2
├── inherits#2.0.1
├── ini#1.1.0
├─┬ init-package-json#0.0.14
│ └── promzard#0.2.1
├─┬ jshint#2.4.4 extraneous
│ ├─┬ cli#0.4.5
│ │ └─┬ glob#3.2.9
│ │ └── inherits#2.0.1
│ ├── console-browserify#0.1.6
│ ├── exit#0.1.2
│ ├─┬ htmlparser2#3.3.0
│ │ ├── domelementtype#1.1.1
│ │ ├── domhandler#2.1.0
│ │ ├── domutils#1.1.6
│ │ └─┬ readable-stream#1.0.26-2
│ │ └─... ├── text-table#0.2.0
├── uid-number#0.0.3
└── which#1.0.5
**npm ERR! extraneous: jshint#2.4.4 C:\Program Files\nodejs\node_modules\npm\node_modules\jshint npm**
Questions:
Why do I get npm ERR! extraneous ...?
What does it mean?
How can I resolve this issue?
Information:
I am on a windows-machine Windows 7, using cygwin as shell.
trying to just the jshint (jshint someTestfile.js) of course does not work.
npm ERR! extraneous means a package is installed but is not listed in your project's package.json.
Since you're listing packages that have been installed globally, it's going to give you a lot of extraneous errors that can be simply ignored because most things installed globally will not be in your project's package.json.
1 & 2: It means you don't have the jshint listed in your project's package.json file but that it is globally installed. So it is not a big problem.
3: To avoid this extraneous error, you can run or re-run the install with the option --save . This will update automatically you package.json file :
npm install -g jshint --save
Or need to update manually your package.json file with a "dependencies": {...}
I resolved this by doing an npm update in the parent package's folder which removed some of the extraneous packages from the list and then did npm uninstall <package> for the remaining few.
Seems to have worked, as I'm getting no errors after doing this.
I solved it by combining all the answers. At first I installed the package globally.
npm install -g packagename --save
Since npm installed this packaged as well globally but did not add it to my local package.json file, I had to do something about it.
I choose, the solution to remove the local one and then install it globally.
npm uninstall packagename
npm install -g packagename
This way I have no more warnings and do not mess up the package.json file.
I my case, I saw this 'npm ERR! extraneous' message in my cygwin terminal when i did an 'npm ls'. I thought this was some sort of a globally corrupted setup after having lots of tinkering. I learn the following observations here:
'npm ls' gives different outputs depending on what is your current folder location.
'npm ls' tries to detect the presence of a 'node_modules' folder in the current folder location, and list out those contents. NOT the global ones!
Furthermore, if the current folder containing 'node_modules' also has a package.json file containing fewer modules listed here, then the error shows.
I 'rm package.json' and 'npm ls' no longer shows error message. So I say, that always check the current location for the presence of 'node_modules' folder and the package.json file because these are prioritize first in the check and if these are missing, the check continues to to the parent folder and so on, and if you have tinkered a lot of code snippets a lot, then you may have scattered around lots and lots of node_modules folder and package.json file. Nothing is really corrupted here, unlike those experiences we have when doing J2EE Java development / eclipse IDE or during the days when we have to use regedit to change settings in Windows.
In my case it was because the package name in its package.json file was not the same as the depency name listed in the package.json of the dependent module. My error, since it's a new module I created, but hard to spot, since npm won't give any clue.
This happened when using the dependencies: { "my-module": "file:local-modules/mymodule" } syntax, with a typo in the name "my-module".
This is due to the fact that your package is not in your package.json. If you add it, the problem will be solved, please look at the image below: