I get the following error when I run jscodeshift -t ./react-codemod/transforms/React-PropTypes-to-prop-types.js ./src
Transformation error (This experimental syntax requires enabling one of the following parser plugin(s): 'decorators-legacy, decorators' (13:0))
I googled a bit and found out I have to set the --parser-config of jscodeshift. I need help with a sample json file that can resolve the above error.
The instructions mentioned in the comment by The Third are correct.
I was need to manually update babel5Compat.js file with this 'decorators-legacy' plugin.
// in ./node_modules/jscodeshift/parser/babel5Compat.js
plugins: [
// a list of plugins,
'decorators-legacy',
]
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 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'm working on a iMX6, with Yocto, and I'm trying to use a Gstreamer plugin : gdkpixbufoverlay on my board, but I got the following error:
gst-launch-1.0 autovideosrc ! gdkpixbufoverlay location=image.png ! autovideosink
(gst-launch-1.0:441): GdkPixbuf-WARNING **: Cannot open pixbuf loader module file '/usr/lib/gdk-pixbuf-2.0/2.10.0/loaders.cache': No such file or directory
This likely means that your installation is broken.
Try running the command
gdk-pixbuf-query-loaders > /usr/lib/gdk-pixbuf-2.0/2.10.0/loaders.cache
to make things work again for the time being.
Setting pipeline to PAUSED ...
ERROR: Pipeline doesn't want to pause.
ERROR: from element /GstPipeline:pipeline0/GstGdkPixbufOverlay:gdkpixbufoverlay0: Could not load overlay image.
Additional debug info:
../../../gst-plugins-good-1.6.3/ext/gdk_pixbuf/gstgdkpixbufoverlay.c(508): gst_gdk_pixbuf_overlay_start (): /GstPipeline:pipeline0/GstGdkPixbufOverlay:gdkpixbufoverlay0:
Couldn't recognize the image file format for file 'image.png'
Setting pipeline to NULL ...
Freeing pipeline ...
So I tried to run the command advised, but I did not work either. I took a look at the output:
/usr/lib/gdk-pixbuf-2.0/gdk-pixbuf-query-loaders
# GdkPixbuf Image Loader Modules file
# Automatically generated file, do not edit
# Created by gdk-pixbuf-query-loaders from gdk-pixbuf-2.32.3
#
# LoaderDir = /usr/lib/gdk-pixbuf-2.0/2.10.0/loaders
#
And the output is full of comments. I think something is wrong on my board but I can't find where.
Did I need some other packages to make gdkpixbuf work?
I tested on Poky distribution, on krogoth and pyro branch, and the result is the same.
Add to your recipe (the image-YOUR_RECIPE_NAME.bb file) the necessary package and sub-packages names as rows.
In my case the package got split, so in order to use PNG and JPEG image overlays, my recipe looks like the following:
...
gdk-pixbuf \
gdk-pixbuf-loader-png \
gdk-pixbuf-loader-jpeg \
...
After saving the changes, don't forget to bitbake it:
bitbake image-YOUR_RECIPE_NAME
I have just started work on a project with some typescript code, and I'm trying to compile the .ts files to .js files from within Linux Mint, but it's not working as I'd expect.
There is a Makefile, but it's not working. Running make returns an error:
tsc --noImplicitAny --noEmitOnError --out client/welcome.js client/welcome.ts
make: *** [client/welcome.js] Error 1
I have also tried creating an example typescript file greeter.ts (as per this official tutorial) containing:
function greeter(person) {
return "Hello, " + person;
}
var user = "Jane User";
document.body.innerHTML = greeter(user);
and tried compiling the ts file to javascript with the command (as per the same tutorial) tsc greeter.ts however the command completes with no output, and no .js file has been created.
I haven't previously worked with typescript at all, and though I've used Makefile's before I don't know much about them either, so I'm hoping it's something really obvious!
I encountered this problem because I had the following line in my tsconfig.json:
"noEmit": true
It worked after removing it.
--noEmitOnError
This means that if there is an error detected no js will be generated. I highly recommend not using this option (Changes a major benefit of why typescript)
More
Check your tsc version. The code you provided works fine with 1.6:
Update
The --version command should work at the very least. See below:
Can phpDocumentor be used to generate HTML docs for some legacy code that does not necessarily conform to its standard?
I'd like to generate some preliminary documentation for an old code tree and later on start improving my comments and add the appropriate # tags as I get fluent with phpDocumentor. I've never used this piece of software before and the examples I've found focus on how to write new code that conforms to its syntax and generate HTML file by file with the -f parameter.
I've installed latest phpDocumentor through the PEAR command line installer and tried this little *.bat file on Windows XP:
#echo off
phpdoc ^
--directory "\\server\project\trunk" ^
--target "C:\tests\project-doc"
... but this is all I get:
PHP Version 5.3.5
phpDocumentor version 1.4.3
Parsing configuration file phpDocumentor.ini...
(found in C:\Archivos de programa\PHP\pear\data/PhpDocumentor/)...
done
Maximum memory usage set at 256M after considering php.ini...
using tokenizer Parser
directory: '' not found
I've also tried mapping the UNC path to a drive letter:
#echo off
phpdoc ^
--directory "I:\" ^
--target "C:\tests\project-doc"
... but:
PHP Version 5.3.5
phpDocumentor version 1.4.3
Parsing configuration file phpDocumentor.ini...
(found in C:\Archivos de programa\PHP\pear\data/PhpDocumentor/)...
done
Maximum memory usage set at 256M after considering php.ini...
using tokenizer Parser
a target directory must be specified
try phpdoc -h
This error message is the same if I create "C:\tests\project-doc" before.
What's exactly wrong in my syntax?
phpDocumentor can indeed run against "undocumented" code. It builds its docs based on the code itself, and uses the docblocks as additional info (and additional organization, in the case of #package and #subpackage tags).
I'd suggest starting with phpDocumentor against your existing code, and work towards clearing out the warnings you see in the errors.html file that results -- this file is generated in the top level of your output docs, but there isn't any link to it from the output docs.
Once you have those cleared, you can start running phpDocumentor with the -ue argument (--undocumentedelements), which will add new warnings to errors.html, highlighting (in much greater detail) things that still need to be documented in docblocks.
Now, as for the issue you're having trying to run the program against code on a shared drive, I'm not sure what's wrong there. The script is clearly able to execute PHP and find the phpDocumentor code itself. You might try putting the arguments in the same line, rather than using the ^ as a line-feed escape character, and perhaps remove the quotes around the paths (since no spaces exist in the paths).
I think I've found what the issue is. The parameter parser is very picky and it doesn't like neither UNC paths nor bare root directories. If I replace this:
--directory "I:\"
... with this:
--directory "I:\."
... it finally starts running.
I suppose it's a bug. Their bug tracker doesn't seem to be public so I don't know if it's a known issue.