I have a large code base using jsdoc. We just noticed that a lot of private methods do not have the #private flag.
Is there a way to set up the config to see all methods that start with an underscore as private? I would really like to avoid having to go through hundreds of files to do it by hand.
I found the answer.
I installed this:
https://www.npmjs.com/package/jsdoc-autoprivate
which is unfortunately lacking in documentation.
In my jsdoc.conf.json, under source, I had to add it as a plugin:
"plugins": [
"node_modules/jsdoc-autoprivate/autoprivate.js"
]
And it works.
In case someone else found this question, jsdoc includes a plugin called underscore which does this nicely:
"plugins": [
"plugins/underscore.js"
]
Related
I was playing around with openapi-generator, and cant find a way to get it to generate valid scala code for scala-play-server.
I use the petstore.json I downloaded from swagger.io, and run
openapi-generator generate -i petstore.json -g scala-play-server
It seems to kinda work, except, the models it generates look like this:
case class Tag(
id: Option[Long],
name: Option[String]
additionalProperties:
)
... which, of course, isn't valid scala code, and fails to compile.
I tried adding
--additional-properties=disallowAdditionalPropertiesIfNotPresent=false
to command line as some website I googled suggested, but that didn't make any difference (and neither did changing false to true).
I guess, I could just put together a sed script, to run on all generated files and replace additionalProperties: with additionalProperties: Map[String, Any] (or just remove those lines completely - no idea why I would want them there), but thought I'd just ask first in case someone knows about an easy fix that wouldn't be this "hacky" ...
Disclaimer, I am not a scala developer, but I spend a lot of time with the open-api-generator.
It appears this is a known bug that was reported in September 2022. However, it doesn't seem to have any comments or traction. Feel free to add comments to the existing ticket. Sometimes that helps them gain visibility.
I don't know if it matters, but I tested the other scala server generators, and all of them generate the class without the additional properties. So, if you are able to use a different scala server generator, that may be a work around.
Another potential work around, if you don't ever plan to use the additionalProperties feature of OAS, would be to remove it from the mustache template. You can do this via templating. Copy the caseClass.mustache and the model.mustache templates into a directory of your choosing, and delete the references to the additionalProperties. Then, add the template directory to your CLI generator via -t/--template.
I tried using the templating method myself and it works, however you will no longer be able to use the additionalProperties feature from OAS in your schema.
How can I autoload a hook in TYPO3?
I register it in the ext_localconf.php, but it does not get autoloaded (unless I 'include' it in the same file which is of course an extremely ugly solution).
I looked into other extensions but I don't find, where the require there hooks.
Shouldn't it be autoloaded in the ext_emconf?
'autoload' => [
'psr-4' => [
'ID\\IndexedSearchAutocomplete\\' => 'Classes'
],
],
But when don't use my ugly solution I get the error, that GeneralUtility::makeInstance can't find my file.
Does this help? http://insight.helhum.io/post/130876393595/how-to-configure-class-loading-for-extensions-in
This article describes the options you have regarding class loading.
You may want to check whether your class fulfills the psr-4 standard: http://www.php-fig.org/psr/psr-4/
I assume that you are using composer in your project. Composer does the whole autoloading of classes. It "knows" all classes of extensions that were required by composer (listed in the require part of your composer.json).
Of course you can add extensions to your project without requiering them with composer. I guess, that is what you did here. In that case you have to tell composer about the classes in your composer.json.
Add a autoload section:
"autoload": {
"psr-4": {
"ID\\IndexedSearchAutocomplete\\": "web/typo3conf/ext/indexed_search_autocomplete/Classes"
}
}
Of course your FQCN have to match the path above your Classes folder (that is what psr-4 means).
After that you can type composer dump-autoload and your class should be loaded.
What's the best way to identify which Visual Studio Code setting is generating / allowing various suggestions to pop up (so it can be turned off)? In particular I'd like to eliminate these three from ever showing.
Those suggestions are types from the standard library. The TypeScript service that powers VS Code's JavaScript and TypeScript language features loads these types from .d.ts files in order to understand the signatures of standard JavaScript library functions such as parseInt or Promise.
To find out where a type is coming from, try using workspace symbol search (cmdT):
In this case, these types come from the standard lib.d.ts file that TypeScript loads automatically. TypeScript will also automatically load a d.ts file for the DOM api.
To disable these suggestions, create a jsconfig.json at the root of your project with the contents:
{
"compilerOptions": {
"lib": []
}
}
This tells typescript not to include any extra typings files for the core libraries. You can also select which typings you want to include:
{
"compilerOptions": {
"lib": [
"es2015"
]
}
}
See the documentation for a list of valid lib options
If you notice any bugs with this behavior or have any suggestions on how this could be improved, please file an issue against VS Code
Update
To discover where a type suggestion is coming from, you may also be able to write:
/**
* #type {AsyncResultObjectCallback}
*/
var placeholer;
And then run go to type definition on placeholder. Even using "lib": [], you may still be seeing suggestions from #types files or node packages that include d.ts files
I'm new to CoffeeScript and seems that I can't find any document generator for CoffeeScript using Javadoc syntax. The only one I could find is available as a patch to the CoffeeScript compiler.
So, what do you use to generate documentation from Javadoc comment on CoffeeScript or how do you document your function arguments and return values?
So, JavaDoc syntax has never really caught on with JavaScript developers. There are those who use something like it—notably Google—but it's kind of at odds with JS, which doesn't have static typing and allows any number of arguments to any function.
If you want to create beautiful documentation with CoffeeScript, the standard is Docco (its home page is an excellent example). If you want to create JavaDoc-style comments for every function... well, you'll have to create them by hand, and escape them with backticks.
Alternatively, you could work in CoffeeScript until your code is release-ready, then document the resulting JavaScript.
Docco is great for prozedural coding style. If you want to document an API, coffeedoc is for you.
People looking forward to using javadoc style documentation in coffeescript can checkout codo ( http://netzpirat.github.com/codo/ ) which provides support for a subset of javadoc and automatically infers class names, function names and parameters from source code.
I'm using YUIDoc. I can add comments using a syntax similar to Javadoc to my classes, methods and events. The documentation gets output as html/css files and you can even customize the page layout.
Check this documentation example: http://yui.github.com/yuidoc/api/
PS: It relies on Node.JS and you need to install the package yuidocjs
npm install yuidocjs -g
Typo3 - Question:
In the extensionmanager when you click on "Information" there often is a (red) error which reads like this: "No XCLASS inclusion code found in file xxxxx".
Especially when developing an extension I am looking for a way to fix this this.
Any ideas?
You need to add the neccessary code in the bottom of your extension code. The extension kickstarter produces one for you, or you could snatch and adapt one from another extension, just make sure you don't change anything but the name of the class/path etc, as there doesn't seem to be much of a fuzzy logic to recognize the XCLASS statements.
Yes, norwebian's answer is right. I just want to add that XCLASS is a concept for extension to extend other extension's (or core) classes.
t3lib_div::makeInstance() takes care of this and looks, whether another class added itself as an XCLASS for this particular class, which should be instantiated.
Thanks for the answers! Here is the code that I found, that has to go in the class files:
if (defined('TYPO3_MODE') && $TYPO3_CONF_VARS[TYPO3_MODE]['XCLASS']['ext/extkey/pi1/class.tx_extkey_pi1.php']) {
include_once($TYPO3_CONF_VARS[TYPO3_MODE]['XCLASS']['ext/extcey/pi1/class.tx_extkey_pi1.php']);
}