I am generating a jsdoc for a open source library. To have a higher consistency I often import the typings from the *.d.ts file, in order to prevent duplicated types.
/**
* Creates the GuildChannelManager for the Guild.
* #param {import('../typings/Managers/CacheManager').Client} client The Cache Manager
* #param {import('../typings/Structures/Channel/').Channel|{}} data Channel Data
* #param {import('../typings/Managers/ChannelManager').Options} options Options for the ChannelManager
*/
constructor(client, data = {}, options = {}) {
VSCode can read the content from the typings file as normal, but the generated jsDoc has a issue, it does not include a reference to the typings nor displays it.
The generated JSDoc should display the available sub options or refer to the typings.
Related
I'm adding #typedef JSDoc comments to the top of Javascript files to help define types (really, so that I can take advantage of some of the typescript benefits without learning it all today).
Where can I store JSDoc typedef information to share across projects in VSCode?
For example, can I store this in some external file and then use it in multiple .js files?
/**
* #typedef {Object} SomeType
* #property {String} id
*/
2021 Update
Edit tsconfig.json so that includes is relative to the root of your project and includes your type files as well. For example:
{
"compilerOptions": {
// ...
},
"include": ["./my-types.js", "src/**/*.js"],
}
If you're not nesting any of your projects under a folder like src/, then this would work on its own:
{
"compilerOptions": {
// ...
},
"include": ["**/*.js"],
}
Original Answer
You can put that code snippet in a .js file and then either add it to the files or include in each tsconfig.json file or use a reference directive:
///<reference path="path/to/shared-file.js" />
(These are the same two options you have for TypeScript declaration files.) It gets a little more complicated if your shared file is an ES6 module (with top-level ES6 imports or exports); then you'll need to either import it or use import types.
I am making a node.js package found here
Development is going well, all except one thing. All of my code is in one file, index.ts.
I googled with no luck on how to separate the classes into different files and then be able to put them all together as a package in the end, while keeping the typescript types and all.
There are many ways to do it, but then they break IntelliSense (the items do not show up). Due to the whole reason I am using typescript is to have IntelliSense, and somewhat inline documentation, that is not a viable option.
Any help would be appreciated.
SOLUTION:
./Help/HelpModule.ts
export enum HelpMode {
/**
* Disable the automatic help command.
*/
Disabled,
/**
* Use the automatic help command and respond in the channel the command is used.
*/
Public,
/**
* Use the automatic help command and respond in a private message.
*/
Private
}
./index.ts
export * from './Help/HelpMode';
To split out your code into multiple files you must first move your functions into a new file, export them, then import them into your new file.
For example
//index.ts
function fooA() { .. }
function fooB() { .. }
If we want to split foo B into its own file. We do:
//index.ts
import { fooB } from "./fooB";
function fooA() { .. }
And the other file would be
//fooB.ts
export function fooB() { .. }
The basic pattern that I have a couple of times in my code is exports.thing = thingFromSomewhereElse, and I want to document the function members of thingFromSomewhereElse as though I had defined them myself. But I can't see how do do that without an actual thing.functionName = function() {...}. If I try to use the #callback tag, JSDoc classifies it as a type definition instead of a member. Is there a way to get it to properly display as an object member?
This can be accomplished by using the #name JSDoc tag. That tag is intended to be used to write a comment for something that would not be recognized by JSDoc. The #kind tag should also be used to indicate that the thing being documented is actually a function, so that the function-specific tags like #param and #return work properly. For the example given, the function would be documented with a comment like this:
/**
* Description of the function
* #name thing.functionName
* #kind function
* #param ...
* #return ...
*/
Does anyone know or has a JSDOC definition library I can use for SS2.0??
The current one I have for SS1.0 looks like the one below, and I use it to plug into my IDE and get autocompletion.
/** * Loads an existing saved search. The saved search could have been created using the UI, or created using nlapiCreateSearch(type, filters, columns) in conjunction with nlobjSearch.saveSearch(title, scriptId).
*<br>API Governance: 5
* #param {String} recType [optional] - The record internal ID of the record type you are searching (for example, customer|lead|prospect|partner|vendor|contact). This parameter is case-insensitive.
* #param {String} searchId - The internal ID or script ID of the saved search. The script ID of the saved search is required, regardless of whether you specify the search type. If you do not specify the search type, you must set type to null and then set the script/search ID.
* #returns {nlobjSearch} nlobjSearch
* #since 2012.1 */
function nlapiLoadSearch(recType, searchId) { };
Not really a technical question but would come in handy for everyone.
You may consider what I did which there is no need to download other plugins. You will be able to enable the code assist if you have the copy of SS2.0 API and then use "#param" and "#type" JSDOC tag.
Then, there will be suggestion every time you type then 'CTRL' + 'SPACE".
Aside from that, your IDE will also provide description for each function.
So this is what will you do.
On your NetSuite accoun, download the SuiteScript 2.0 JavaScript files. You can do this by nagaviting at >Documents>Files>SuiteScripts>. Then at right portion of your screen, you should see links for "SuiteScript 2.0 API" and "SuiteSCript 1.0 API". Click for SS2.0 to download.
On Eclipse IDE, create a new JavaScript project for SS2.0 or include it on your existing project.
Next on the project you are working, right click then select “Properties”. Under >JavaScript>Include Path and then at “Projects” subtab, add the project where SS2.0 APIs are included.
You will now have code assist for object literal APIs of SS2.0. These are 'N/log' and 'N'util' modules.
Next to enable the code assist for object constructor APIs of SS2.0 like 'N/record' and 'N/search' modules, we should be adding "#param" JSDoc tag on each function declaration.
So if we are going to use the 'N/record', 'N/search' and 'N/error' modules in our script, we should have below sample comments before function declaration. But please take note that it should match the value inside the "{[VALUE HERE]}" tag and the module name. Also the variable name on the comment section and function declaration.
/**
* Do something.
*
* #param {record} objRec
* #param {search} objSearch
* #param {error} objError
*
*/
function doSomething(objRec, objSearch, objError)
{
//CODE HERE
}
You may also use '#type' for your variable declaration. Below is the sample code.
/**
* Do something.
*
*/
function doSomething()
{
/*** #type record**/
var recCustomerRefund = record.create(
{
type : 'customerrefund',
isDynamic : true
});
}
The way SS2 works you are essentially out of luck.
consider
define(['N/search'], function(bob){
var srch = bob.load({id:'customsearch_my_search'});
}
What is bob? Your IDE will have to be considerably smarter to know that bob is part of the search namespace. It's of course doable but less likely to work with a simple downloadable file that you can just plug into your IDE. If you just use 'search' that may make things more likely to work but now you've used up a very generic name that you cannot use elsewhere.
Also if an IDE can determine what 'bob' is now your arguments is an unordered hash so positional #params don't work anymore.
Typescript may help. I've been maintaining a Typescript definition file for SS1 at https://github.com/BKnights/KotN-Netsuite. As I start doing more with SS2.0 I may do the same for that. Then your IDE would have more of a chance:
define(['N/search'], function(bob:NSearch){...
So your Typescript aware IDE could use that for member completion and at least you'd have a compile time check on types
I'm running grunt jsdoc module and the output html is missing the filenames in the table of contents.
See image:
Notice the js repeated in right hand column under modules
Top of file (AMD):
/** #module identity.js
*
* abstracts the logic for obtaining a user's identity
* #module identity.js
* #type {Core}
*/