I run locally on my project the following command
gometalinter --config=gometalinter.json ./...
at the beginning I got some errors and I was fixed them all!
now I run the same command exaclty in Travis script
and I got vendor errros like
vendor/github.com/spf13/viper/flags.go:3:8:warning: error return value not checked (could not import github.com/spf13/pflag (go/build: importGo github.com/spf13/pflag: exit status 1) (errcheck)
vendor/github.com/spf13/viper/viper.go:42:7:warning: error return value not checked (could not import github.com/pelletier/go-toml (go/build: importGo github.com/pelletier/go-toml: exit status 1) (errcheck)
This is the gometalinter.json for the config
{
"vendor": true,
"Deadline": "2m",
"Sort": [
"linter",
"severity"
],
"DisableAll": true,
"Enable": [
"gotypex",
"vetshadow",
"errcheck",
"gocyclo",
"vet",
"golint",
"vetshadow",
"ineffassign",
],
"Cyclo": 10,
"LineLength": 120
}
I dont understand why locally I dont get this error (i've the vendor repo) and why it ask for vendor error ? what could be the reason ?
gometalinter runs binaries in your path to do its check. I have had problems where my CI would have one set of binaries versions while my local development environment would have different versions.
Try updating all the required binaries on your local machine.
Try --vendor flag and check versions of gometalinter and all used linters.
Extract from gometalinter documentation:
How do I make gometalinter work with Go 1.5 vendoring?
gometalinter has a --vendor flag that just sets
GO15VENDOREXPERIMENT=1, however the underlying tools must support it.
Ensure that all of the linters are up to date and built with Go 1.5
(gometalinter --install --force) then run gometalinter --vendor ..
That should be it.
Related
I've checked out the main branch of github.com/Shopify/sarama (at commit 947343309601b4eb3c2fa3e7d15d701b503dd491 ) but I notice that in VS Code I can't "Go to definition" as usual. If I hover over the package name sarama in functional_consumer_group_test.go, I get the linter warning
No packages found for open file /Users/kurtpeek/go/src/github.com/Shopify/sarama/functional_consumer_group_test.go: <nil>.
If this file contains build tags, try adding "-tags=<build tag>" to your gopls "buildFlags" configuration (see (https://github.com/golang/tools/blob/master/gopls/doc/settings.md#buildflags-string).
Otherwise, see the troubleshooting guidelines for help investigating (https://github.com/golang/tools/blob/master/gopls/doc/troubleshooting.md).go list
(See screenshot below).
From the command line, if I try to gopls that file, I get a similar error:
> gopls check functional_consumer_group_test.go
gopls: no packages returned: packages.Load error
I suspect this has something to do with the build constraints (https://pkg.go.dev/cmd/go#hdr-Build_constraints) in that file, from https://github.com/Shopify/sarama/blob/947343309601b4eb3c2fa3e7d15d701b503dd491/functional_consumer_group_test.go#L1-L2,
//go:build functional
// +build functional
It's not clear to me, however, how to modify my VS Code settings.json to pass these build constraints. Does anyone know how to get this functional test to build?
Following https://www.ryanchapin.com/configuring-vscode-to-use-build-tags-in-golang-to-separate-integration-and-unit-test-code/, I had to create a .vscode/settings.json file in the repository's root directory and add the following contents:
{
"go.buildFlags": [
"-tags=functional"
],
"go.testTags": "functional",
}
Now VS Code works like normal in that file:
Have you tried go clean -cache?
And this link may help:
https://github.com/golang/go/issues/42353
This worked for me!
by adding it in .vscode/settings.json
{
"gopls.env": {
"GOFLAGS": "-tags=test"
}
}
I am trying to build a simple web project
project structure like this
-src
--index.html
--index.js
--style.css
package.json
yarn.lock
I installed parcel-bundler with this
yarn global add parcel-bundler
And I run the parcel build command
parcel build src/index.html
But error has occurred followed by this log
D:\playground\js\sample>parcel build src/index.html
× D:\playground\js\sample\src\style.css:undefined:undefined: plugin is not a function
at LazyResult.run (C:\Users\pc\AppData\Roaming\nvm\v15.14.0\node_modules\parcel-bundler\node_modules\postcss\lib\lazy-result.js:288:14)
at LazyResult.asyncTick (C:\Users\pc\AppData\Roaming\nvm\v15.14.0\node_modules\parcel-bundler\node_modules\postcss\lib\lazy-result.js:212:26)
at C:\Users\pc\AppData\Roaming\nvm\v15.14.0\node_modules\parcel-bundler\node_modules\postcss\lib\lazy-result.js:254:14
at new Promise (<anonymous>)
at LazyResult.async (C:\Users\pc\AppData\Roaming\nvm\v15.14.0\node_modules\parcel-bundler\node_modules\postcss\lib\lazy-result.js:250:23)
at LazyResult.then (C:\Users\pc\AppData\Roaming\nvm\v15.14.0\node_modules\parcel-bundler\node_modules\postcss\lib\lazy-result.js:131:17)
I'm just following the instruction of parcel's official docs
I cannot find a solution
please help me
Try --no-minify
Why is the accepted answer, "throw out the baby with the bathwater?"
parcel-bundler does still work, but instead of fixing what's broken, it's been abandoned for Parcel 2, which DOES NOT support Vue 2 SFCs.
Building a Rails 6/Vue 2 app and converting to parcel from webpack(er), so Parcel 2 is not an option for me. (Demanding people upgrade, and then not providing an upgrade path or decent docs, reminds me too much of webpack!)
parcel build ./app/packs/entrypoints/*.js --no-minify
This disables minification, which at least eliminates this particular error for me.
Problem solved: parcel-bundler is deprecated. Use 'parcel' not 'parcel-bundler'
package.json
If you have preset the scripts...
"scripts": {
"start": "parcel index.html",
"dev": "parcel index.html",
"build": "parcel build index.html"
},
...simply run
npm run build
otherwise use this syntax:
npm run build index.html
Replace index.html to whatever file you want to build, but make sure it is the same type of file.
I am a newbie in go and go-swagger. I am following steps in Simple Server tutorial in goswagger.io.
I am using Ubuntu 18.04, swagger v0.25.0 and go 1.15.6.
Following the same steps, there are a few differences of the files generated. For instance, goswagger.io's has find_todos_okbody.go and get_okbody.go in models but mine does not. Why is that so?
Link to screenshot of my generated files vs
Link to screenshot of generated files by swagger.io
Starting the server as written in the tutorial go install ./cmd/todo-list-server/ gives me the following error. Can anyone please help with this?
# my_folder/swagger-todo-list/restapi
restapi/configure_todo_list.go:41:8: api.TodosGetHandler undefined (type *operations.TodoListAPI has no field or method TodosGetHandler)
restapi/configure_todo_list.go:42:6: api.TodosGetHandler undefined (type *operations.TodoListAPI has no field or method TodosGetHandler)
The first step in goswagger.io todo-list is swagger init spec .... Which directory should I run this command in? I ran it in a newly created folder in my home directory. However, from the page, it shows the path to be ~/go/src/github.com/go-swagger/go-swagger/examples/tutorials/todo-list. I am not sure whether I should use go get ..., git clone ... or create those folders. Can someone advise me?
Thanks.
This is likely the documentation lagging behind the version of the code that you are running. As long as it compiles, the specific files the tool generates isn't so crucial.
This is a compilation error. When you do go install foo it will try to build the foo package as an executable and then move that to your GOPATH/bin directory. It seems that the generated code in restapi/configure_todo_list.go isn't correct for the operations code generated.
All you need to run this tutorial yourself is an empty directory and the swagger tool (not its source code). You run the commands from the root of this empty project. In order not to run into GOPATH problems I would initialise a module with go mod init todo-list-example before doing anything else.
Note that while the todo-list example code exists inside the go-swagger source, it's there just for documenting example usage and output.
What I would advice for #2 is to make sure you're using a properly released version of go-swagger, rather than installing from the latest commit (which happens when you just do a go get), as I have found that to be occasionally unstable.
Next, re-generate the entire server, but make sure you also regenerate restapi/configure_todo_list.go by passing --regenerate-configureapi to your swagger generate call. This file isn't always refreshed because you're meant to modify it to configure your app, and if you changed versions of the tool it may be different and incompatible.
If after that you still get the compilation error, it may be worth submitting a bug report at https://github.com/go-swagger/go-swagger/issues.
Thanks #EzequielMuns. The errors in #2 went away after I ran go get - u -f ./... as stated in
...
For this generation to compile you need to have some packages in your GOPATH:
* github.com/go-openapi/runtime
* github.com/jessevdk/go-flags
You can get these now with: go get -u -f ./...
I think it's an error of swagger code generation. You can do as folloing to fix this:
delete file configure_todo_list.go;
regenerate code.
# swagger generate server -A todo-list -f ./swagger.yml
Then, you can run command go install ./cmd/todo-list-server/, it will succeed.
I try to configure elm-coverage to be used in CI.
Installation was successful, installed using yarn as "elm-coverage": "0.2.0"
Our most recent command for running tests is
./node_modules/.bin/elm-test --compiler ./node_modules/.bin/elm app/frontend/elm/tests/
app/frontend/ is there, because elm app is within repository of rails app.
When I try to use coverage
elm-coverage --elm-test ./node_modules/.bin/elm-test -- --compiler ./node_modules/.bin/elm app/frontend/elm/tests/
in (ruby app's) root, it returns
MacBook-Pro-6:enectiva admin$ elm-coverage --elm-test ./node_modules/.bin/elm-test -- --compiler ./node_modules/.bin/elm app/frontend/elm/tests/
/Users/admin/git.enectiva.cz/enectiva/node_modules/elm-coverage/node_modules/find/index.js:33
throw err;
^
Error: does not exist.
at Object.notExist (/Users/admin/git.enectiva.cz/enectiva/node_modules/elm-coverage/node_modules/find/index.js:41:12)
at traverseAsync (/Users/admin/git.enectiva.cz/enectiva/node_modules/elm-coverage/node_modules/find/index.js:163:28)
at /Users/admin/git.enectiva.cz/enectiva/node_modules/elm-coverage/node_modules/find/index.js:282:7
at _combinedTickCallback (internal/process/next_tick.js:131:7)
at process._tickCallback (internal/process/next_tick.js:180:9)
Otherwise, I tried
MacBook-Pro-6:enectiva admin$ elm-coverage app/frontend/elm/tests/ --elm-test ./node_modules/.bin/elm-test
[12:57:01.68] Instrumenting sources...
[12:57:01.89] Something went wrong:
I searched through issues in Github repository, it does not seem to be reported bug, so there must be something I missed.
Does anyone know, how to actually use it?
OK, I've had a bit more of a play with elm-coverage, as I've been able to get it to run on an Elm project of mine.
Firstly elm-coverage has a --verbose flag which adds extra logging, so try running with that.
I've had best results if I cd to the folder containing my elm.json file and run elm-coverage from there. In your case, this would look something like the following:
cd app/frontend/elm && elm-coverage [source folder] --elm-test ../../../node_modules/.bin/elm-test
[source folder] is the name of the folder containing your source files (not the tests). For me, [source folder] is src, but because that's the default I can omit it.
I've installed Cloud9 IDE on my linux machine in order to play around with it a bit (I had to use nodejs 0.8 because cloud9 uses a package that depends on node-waf, which is no longer supported by higher versions of nodejs).
I can start it up without problems, however when I try to access Cloud9 via browser, it constantly gives me the error message: File already exists.. Here's a trace from the log:
Error: File already exists.
at module.exports.from (/home/xyz/repos/cloud9/node_modules/vfs-local/localfs.js:678:35)
at Object.fs.exists [as oncomplete] (fs.js:91:19)
Relevant code section:
exists(topath, function(exists){
if (options.overwrite || !exists) {
// Rename the file
fs.rename(frompath, topath, function (err) {
if (err) return callback(err);
// Rename metadata
if (options.metadata !== false) {
rename(WSMETAPATH + from, {
to: WSMETAPATH + to,
metadata: false
}, function(err){
callback(null, meta);
});
}
});
}
else {
var err = new Error("File already exists.");
err.code = "EEXIST";
callback(err);
}
When the error occurs, the topath variable is set to the workspace settings file (/home/xyz/repos/cloud9/workspace/.settings)
Has anyone else had an error like this? How can I resolve it?
thx in advance
Reinstalling cloud9
First option, maybe you could try using this workaround installation procedure:
https://github.com/ajaxorg/cloud9/issues/2904#issuecomment-22518669
Second option, if you are willing to always use an older node-version for running cloud9 as you indicated, I used the following installation procedure and it worked (assuming you already installed nvm). Then you can still use the cloud9.sh-file for starting:
git clone git://github.com/ajaxorg/cloud9.git
cd cloud9
nvm install 0.8.8
sed -i -e 's/~//g' package.json
npm config set ca=""
npm install
sed -i s/connect.session.file/connect.session.memory/ configs/default.js
Not sure if 0.8.8 is the best node-version for cloud9 but it works for me :)
Last step seems necessary because of https://github.com/ajaxorg/cloud9/issues/2005#issuecomment-11372587 :)
Then before starting cloud9 you always have to enter:
nvm use 0.8.8
Or you set 0.8.8 as the default node version if you don't use node much otherwise:
nvm alias default 0.8.8
Fix problem without reinstalling
Third option, if you don't want to repeat the installation procedure you could try just reinstalling the vfs-local-module in the cloud9 directory:
npm install vfs-local#0.3.4
Haven't tested this though :)