{"id":13342835,"url":"https://github.com/szkiba/tygor","last_synced_at":"2026-01-19T12:02:04.730Z","repository":{"id":208986916,"uuid":"722954588","full_name":"szkiba/tygor","owner":"szkiba","description":"API-First approach k6 extension development","archived":false,"fork":false,"pushed_at":"2024-06-10T10:23:28.000Z","size":1045,"stargazers_count":3,"open_issues_count":7,"forks_count":0,"subscribers_count":2,"default_branch":"master","last_synced_at":"2025-02-10T08:21:19.894Z","etag":null,"topics":["xk6"],"latest_commit_sha":null,"homepage":"","language":"Go","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"agpl-3.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/szkiba.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":"CONTRIBUTING.md","funding":null,"license":"LICENSE","code_of_conduct":"CODE_OF_CONDUCT.md","threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2023-11-24T10:41:15.000Z","updated_at":"2024-12-02T12:49:01.000Z","dependencies_parsed_at":"2024-10-24T05:19:39.660Z","dependency_job_id":"d8d97e80-1245-4174-bbf4-3ae1f46fb30b","html_url":"https://github.com/szkiba/tygor","commit_stats":null,"previous_names":["szkiba/tygor"],"tags_count":3,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/szkiba%2Ftygor","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/szkiba%2Ftygor/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/szkiba%2Ftygor/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/szkiba%2Ftygor/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/szkiba","download_url":"https://codeload.github.com/szkiba/tygor/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":247266482,"owners_count":20910832,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["xk6"],"created_at":"2024-07-29T19:30:06.026Z","updated_at":"2026-01-19T12:02:04.723Z","avatar_url":"https://github.com/szkiba.png","language":"Go","funding_links":[],"categories":[],"sub_categories":[],"readme":"# ｔｙｇｏｒ\n\n**API-First approach k6 extension development**\n\nThe functionality of [k6](https://k6.io) can be extended using [JavaScript Extensions](https://k6.io/docs/extensions/get-started/create/javascript-extensions/), which can be created in the go programming language. **tygor** allows you to develop these extensions using an [API-First approach](https://swagger.io/resources/articles/adopting-an-api-first-approach/). A [TypeScript declaration file](https://www.typescriptlang.org/docs/handbook/declaration-files/introduction.html) can be used as [IDL](https://en.wikipedia.org/wiki/Interface_description_language) to define the JavaScript API of the extension.\n\nFrom the TypeScript declaration file, tygor generates the go interfaces needed to implement the API, as well as the binding code between the go implementation and the JavaScript runtime. In addition, tygor is also able to generate a skeleton implementation to help create a go implementation.\n\n**Features**\n\n- uses a TypeScript declaration file to define the JavaScript API\n- generates go interfaces matching JavaScript API\n- generates bindings between JavaScript and go\n- generates api documentation in Markdown or HTML format\n- inserts the API documentation into an outer document (eg: README.md)\n- all generated output can be updated when the API definition changes\n- enables to focus only on implementing the extensions's business logic\n- a single binary without dependencies\n\nCurrently, tygor is still in a relatively early stage of development, but it is already usable. The binding code generation will change in the future (e.g. due to optimization), but this will probably not affect the go interfaces to be implemented. That is, it will be sufficient to regenerate the binding code with the new version of tygor. See the [roadmap](#roadmap) section for more information.\n\n\n## Crash course\n\u003cdetails\u003e\n\u003csummary\u003eClick to expand...\u003c/summary\u003e\n\nIn short, for this TypeScript API:\n\n```ts\nexport as namespace hitchhiker;\n\ntype int = number;\n\nexport declare class Guide {\n  question: string;\n  readonly answer: int;\n\n  constructor(question: string);\n  check(value: int): boolean;\n}\n\ndeclare const defaultGuide: Guide;\n\nexport default defaultGuide;\n```\n\n..these generated interfaces have to be implemented in go language:\n\n```go\ntype goGuide interface {\n  checkMethod(valueArg int) (bool, error)\n  questionGetter() (string, error)\n  questionSetter(v string) error\n  answerGetter() (int, error)\n}\n\ntype goModule interface { \n  newGuide(questionArg string) (goGuide, error)\n  defaultGuideGetter() (goGuide, error)\n}\n\ntype goModuleConstructor func(vu modules.VU) goModule\n```\n\n...and that's it! The rest is handled by the go code generated by tygor.\n\nAfter that, the extension will be usable in [k6](https://k6.io/) like this:\n\n```js\nimport guide, { Guide } from \"k6/x/hitchhiker\"\n\nexport default function() {\n  console.log(guide.answer)                           // 42\n  console.log(guide.check(13))                        // false\n  console.log(guide.check(42))                        // true\n\n  const other = new Guide(\"What is life all about?\")\n  console.log(other.answer)                           // 42\n  console.log(other.question)                         // What is life all about?\n\n  other.question = \"Why are we here?\"\n\n  console.log(other.question)                         // Why are we here?\n}\n```\n\u003c/details\u003e\n\nSee the complete example in the [examples/hitchhiker](examples/hitchhiker) directory. There are more examples in the [examples](examples) directory.\n\nCheck out the [intro slides](https://ivan.szkiba.hu/tygor/intro/) for a quick introduction.\n\n## Install\n\nPrecompiled binaries can be downloaded and installed from the [Releases](https://github.com/szkiba/tygor/releases) page.\n\nIf you have a go development environment (probably you do), the installation can also be done with the following command:\n\n```bash\ngo install github.com/szkiba/tygor@latest\n```\n\n## Usage\n\nCheck [CLI Reference](#cli-reference) section for detailed command line usage.\n\nThe following example generates the `hitchhiker_bindings.go` file containing the go interfaces and bindings and the `hitchhiker_skeleton.go` file containing the skeleton implementation from the `hitchhiker.d.ts` declaration file in the current directory. By default, generated files are placed in the same directory as the declaration file.\n\n```bash\n$ # generate both bindings and skeletons\n$ tygor --skeleton hitchhiker.d.ts       \n$ ls\nhitchhiker_bindings.go\nhitchhiker_skeleton.go\nhitchhiker.d.ts\n```\n\nThe skeleton file can be used as a sample for the implementation. Since it contains a special go build tag (`//go:build skeleton`), its presence will not interfere with the real implementation. To start the implementation, simply copy the skeleton file under a different name (or rename it) and delete the comments at the beginning of the file. If the declaration file changes, the bindings and skeleton can be regenerated at any time, and the skeleton can be used to help implement the changes.\n\nIn the above example, the implementation can be started simply by copying the `hitchhiker_skeleton.go` file in the `hitchhiker.go` file.\n\n```bash\n$ cp hitchhiker_skeleton.go hitchhiker.go\n```\n\nDon't forget to delete the following two comment lines from the beginning of the `hitchhiker.go` file\n\n```go\n// Code generated by tygor; DO NOT EDIT.\n//go:build skeleton\n```\n\nSee also the [tygor](#tygor) command.\n\nThe command below inserts the generated API documentation into the `README.md` file at the location marked with marker comments:\n\n```bash\n# generate and inject API documentation\n$ tygor doc --inject README.md hitchhiker.d.ts\n```\n\nSee also the [tygor doc](#tygor-doc) command.\n\n## Declarations\n\nThis section describes the TypeScript declarations that can be used in the API definition.\n\n### `interface`\n\nOne of the typical uses of the interface declaration is to describe the class implemented by the extension, which cannot be instantiated from the JavaScript code. The other typical use is the description of the object that contains the optional function/method parameters.\n\nThe interface declaration can contain [property](#property) and [method](#method) declarations and its name typically begins with a capital letter.\n\nA go interface is created from the interface declaration, with a name consisting of the `go` prefix and the declared interface name.\n\n\u003cdetails\u003e\u003csummary\u003eTypeScript\u003c/summary\u003e\n\n```ts\nexport declare interface Interface1 {\n  // property declarations\n  // method declarations\n}\n```\n\n\u003c/details\u003e\n\n\u003cdetails\u003e\u003csummary\u003ego\u003c/summary\u003e\n\n```go\ntype goInterface1 interface {\n  // methods\n  // property getters\n  // property setters\n}\n```\n\n\u003c/details\u003e\n\n#### `property`\n\nGetter and setter methods are created from the property declaration in the containing go interface. In the case of a `readonly` property, only a getter method is created. The getter method name consists of the property name and the `Getter` suffix, while the setter method name consists of the property name and the `Setter` suffix. The getter method returns the value of the property and, in case of an error, an error value. The setter method returns an error value in case of an error. The property types are mapped as described in the [type](#type) section.\n\nThe property name typically starts with a lowercase letter.\n\n\u003cdetails\u003e\u003csummary\u003eTypeScript\u003c/summary\u003e\n\n```ts\nexport declare interface Interface1 {\n  prop1 : number;\n  readonly prop2 : string;\n}\n```\n\n\u003c/details\u003e\n\n\u003cdetails\u003e\u003csummary\u003ego\u003c/summary\u003e\n\n```go\ntype goInterface1 interface {\n  prop1Getter() (float64, error)\n  prop1Setter(v float64) error\n  prop2Getter() (string, error)\n}\n```\n\n\u003c/details\u003e\n\n#### `method`\n\nA method is created from the method declaration in the containing go interface. The name of the go method is the declared name plus the `Method` suffix. The parameters of the go method correspond to the parameters of the declared method. The parameter types are mapped as described in the [type](#type) section.\n\nThe method name typically starts with a lowercase letter.\n\n\u003cdetails\u003e\u003csummary\u003eTypeScript\u003c/summary\u003e\n\n```ts\nexport declare interface Interface1 {\n  method1(arg1:number, arg2:boolean) : number;\n}\n```\n\n\u003c/details\u003e\n\n\u003cdetails\u003e\u003csummary\u003ego\u003c/summary\u003e\n\n```go\ntype Interface1 interface {\n  method1Method(arg1Arg float64, arg2Arg bool) (float64, error)\n}\n```\n\n\u003c/details\u003e\n\n### `class`\n\nA typical use of a class declaration is to describe classes implemented by an extension that can be instantiated from JavaScript code.\n\nThe class declaration can contain [constructor](#constructor), [property](#property) and [method](#method) declarations and its name typically begins with a capital letter.\n\n\u003cdetails\u003e\u003csummary\u003eTypeScript\u003c/summary\u003e\n\n```ts\nexport declare class Class1 {\n  // property declarations\n  // method declarations\n  // constructor declaration\n}\n```\n\n\u003c/details\u003e\n\n\u003cdetails\u003e\u003csummary\u003ego\u003c/summary\u003e\n\n```go\ntype goClass1 interface {\n  // methods\n  // property getters\n  // property setters\n}\n\ntype goModule interface {\n  newClass1() (goClass1, error)\n}\n```\n\n\u003c/details\u003e\n\n#### `constructor`\n\nFactory methods are created from the constructor declarations in the module's go interface (`goModule`). The parameters of the factory method correspond to the parameters of the constructor, and its return value is the go interface belonging to the class declaration or an error in case of an error. The name of the factory method consists of the `new` prefix and the declared name of the class.\n\n\u003cdetails\u003e\u003csummary\u003eTypeScript\u003c/summary\u003e\n\n```ts\nexport declare interface Class1 {\n  // properties and methods\n  constructor(arg1:number, arg2:string);\n}\n```\n\n\u003c/details\u003e\n\n\u003cdetails\u003e\u003csummary\u003ego\u003c/summary\u003e\n\n```go\ntype goClass1 interface {\n  // property setters, getters and methods\n}\n\ntype goModule interface {\n  newClass1(arg1Arg float64, arg2Arg string) (goClass1, error)\n}\n```\n\n\u003c/details\u003e\n\n### `namespace`\n\nThe name of the k6 extension can be specified using the `export as namespace` declaration. Using local or nested namespace declarations is not supported. The generated `register()` function uses the namespace name to register the extension under the `k6/x/` path.\n\nAn interface declaration named `Module` is implicitly created from the variables and functions of the namespace. Variable declarations become property declarations (constant variables become readonly properties), and function declarations become method declarations in the implicit `Module` interface.\n\nThe go interface (`goModule`) belonging to the `Module` interface, also contains the factory methods of the go interfaces belonging to the class declarations. These methods are used in the generated code to instantiate go interfaces. The `goModule` interface is instantiated using a `goModuleConstructor` type function. This function must be implemented by the extension developer. The [modules.VU](https://pkg.go.dev/go.k6.io/k6/js/modules#VU) interface can be used as a parameter.\n\n\u003cdetails\u003e\u003csummary\u003eTypeScript\u003c/summary\u003e\n\n```ts\nexport as namespace module1;              // export declare interface Module {\nexport declare var variable1: boolean;    //   variable1: boolean;\nexport declare const variable2: string;   //   readonly variable2: string;\nexport declare function func1(): number;  //   func1(): number;\n                                          // }\n```\n\n\u003c/details\u003e\n\n\u003cdetails\u003e\u003csummary\u003ego\u003c/summary\u003e\n\n```go\ntype goModule interface {\n  variable1Getter() (bool, error)\n  variable1Setter(v bool) error\n  variable2Getter() (string, error)\n  func1Method() (float64, error)\n\n  // factory methods for classes\n}\n\ntype goModuleConstructor func(vu modules.VU) goModule\n\nfunc register(ctor goModuleConstructor) {\n  // ...\n\tmodules.Register(\"k6/x/module1\", m)\n}\n\n```\n\u003c/details\u003e\n\n\u003cdetails\u003e\u003csummary\u003eskeleton\u003c/summary\u003e\n\n```go\ntype goModuleImpl struct {}\n\nvar _ goModule = (*goModuleImpl)(nil)\n\nfunc newModule(_ modules.VU) goModule {\n\treturn new(goModuleImpl)\n}\n\nfunc init() {\n\tregister(newModule)\n}\n```\n\n\u003c/details\u003e\n\n### `type`\n\nThe type alias declaration can be used to define a mapping different from the default type mapping. Currently, it can be defined for the `number` type in the form of a type alias to which go type it should be mapped.\n\n\u003cdetails\u003e\n  \u003csummary\u003eTypeScript\u003c/summary\u003e\n\n```ts\ntype int = number;\n\nexport declare interface Interface1 {\n  prop1 : int;\n}\n```\n\n\u003c/details\u003e\n\n\u003cdetails\u003e\n  \u003csummary\u003ego\u003c/summary\u003e\n\n```go\ntype Interface1 interface {\n  prop1Getter() (int, error)\n  prop1Setter(v int) error\n}\n```\n\n\u003c/details\u003e\n\n\nDefault type mappings:\n\njs/ts | go\n-----------|--------\nnumber     | float64\nstring     | string\nboolean    | bool\nArrayBuffer| []byte\nDate       | time.Time\nany        | interface{}\nobject     | interface{}\n\nSupported type aliases:\n\n```ts\ntype int    = number;\ntype int8   = number;\ntype int16  = number;\ntype int32  = number;\ntype int64  = number;\ntype uint   = number;\ntype uint8  = number;\ntype uint16 = number;\ntype uint32 = number;\ntype uint64 = number;\n\ntype float32 = number;\ntype float64 = number;\n\ntype rune = number;\ntype byte = number;\n```\n\n## Roadmap\n\nCurrently, tygor is still in a relatively early stage of development. Many features have not yet been implemented, and there are still many opportunities to optimize the generated binding code. The following (non-exhaustive) list contains planned future developments:\n\n- array type support (`Array\u003cT\u003e`)\n- record type support (at least `Record\u003cstring, T\u003e`)\n- property adapter optimization (for properties of `interface` or `class` type)\n- improving the go code generator\n- improving the documentation generator\n\n## How It Works\n\n`tygor` runs the TypeScript compiler using a built-in JavaScript interpreter ([goja](https://github.com/dop251/goja)). [Using the TypeScript Compiler API](https://github.com/microsoft/TypeScript/wiki/Using-the-Compiler-API), the extractor (implemented in TypeScript) generates a JSON string from the declaration file, which contains the declarations and their [TSDoc](https://tsdoc.org/) documentation comments. This JSON string is parsed by the go code and this is how the API model is created.\n\nThe generator subcommands generate output in different formats from the API model.\n\n**doc**\n\nThe [`doc`](#tygor-doc) subcommand generates Markdown/HTML documentation from the API model. The generation is done using go template. The [slim-sprig](https://github.com/go-task/slim-sprig) template function library used in the template. The generated Markdown text will be formatted using [blackfriday](https://github.com/russross/blackfriday) (with [markdownfmt](https://github.com/shurcooL/markdownfmt) as renderer). The HTML output is generated from the markdown output using [blackfriday](https://github.com/russross/blackfriday).\n\nYou can specify your own Markdown template using the `--template` flag. The [default Markdown template](internal/doc/doc.gtpl) is a good starting point for creating your own Markdown template. \n\nBoth Markdown and HTML output can be inserted into an outer document, in a place marked by so-called marker comments:\n\n```html\n\u003c!-- begin:api --\u003e\ngenerated API documentation goes here\n\u003c!-- end:api --\u003e\n```\n\nThe [default HTML outer document](internal/doc/outer.html) is a good starting point for creating your own HTML outer document.\n\nDocumentation for extensions usually includes common sections. For example, how to build k6 with the extension, or download pre-built k6 binaries, etc.\n\nFor different extensions, these boilerplate documentation sections differ almost only in the extension name and the repository URL. Consequently, these sections can be easily generated.\n\nThe [`doc`](#tygor-doc) subcommand can generate these boilerplate sections if the necessary parameters (eg repository name) are specified or detected. Thus, the extension developer does not have to write these sections, and if the tooling changes (e.g. the xk6 tool changes or improves), they are simply re-generable.\n\nBy default, GitHub repository and generateable boilerplate sections are automatically detected. This is done by examining the git configuration, the GitHub workflows configuration, and the examples directory.\n\n**parse**\n\nThe [`parse`](#tygor-parse) subcommand simply displays (or writes to a file) the API model in JSON format. With its use, the API model can be processed by external programs without the complexity of TypeScript parsing.\n\n**gen**\n\nThe [`gen`](#tygor-gen) subcommand generates go source code from the API model using the [Jennifer](https://github.com/dave/jennifer) go source code generator.\n\nThe go interfaces to be implemented and the JavaScript binding code are placed in the file with the `_bindings.go` suffix. And the file with the suffix `_skeleton.go` contains the skeleton implementations (this is optional). The call to register the extension is placed in the `init()` function of the skeleton file.\n\nThe generated binding code performs bidirectional mapping between JavaScript and go objects.\n\n# CLI Reference\n\u003c!-- begin:cli --\u003e\n## tygor\n\nCLI tool that enables the development of k6 extensions with an API-First approach.\n\n### Synopsis\n\nThe functionality of k6 can be extended using JavaScript Extensions, which can be created in the go programming language. Tygor allows you to develop these extensions using an API-First approach. A TypeScript declaration file can be used as IDL to define the JavaScript API of the extension.\n\nFrom the TypeScript declaration file, tygor generates the go interfaces needed to implement the API, as well as the binding code between the go implementation and the JavaScript runtime. In addition, tygor is also able to generate a skeleton implementation to help create a go implementation.\n\nThe skeleton file can be used as a sample for the implementation. Since it contains a special go build tag (//go:build skeleton), its presence will not interfere with the real implementation. To start the implementation, simply copy the skeleton file under a different name (or rename it) and delete the comments at the beginning of the file. If the declaration file changes, the bindings and skeleton can be regenerated at any time, and the skeleton can be used to help implement the changes.\n\nThe only mandatory argument is the name of the declaration file (which file name must end with a .d.ts suffix). In addition, different flags can be used to modify the generation output. \n\nThe tygor command generates go source code by default, but it can also generate other outputs. Other outputs can be generated using subcommands. Using it without the subcommand is equivalent to using the gen subcommand.\n\nUse the -h flag to get detailed help on subcommands and flags.\n\n\n```\ntygor file [flags]\n```\n\n### Examples\n\n```\n$ tygor --skeleton hitchhiker.d.ts\n```\n\n### Options\n\n```\n  -h, --help             help for tygor\n  -o, --output string    output directory (default: same as input)\n  -p, --package string   go package name (default: module name)\n  -s, --skeleton         enable skeleton generation (default: disabled)\n```\n\n### SEE ALSO\n\n* [tygor doc](#tygor-doc)\t - Generate documentation from k6 extension's API definition.\n* [tygor gen](#tygor-gen)\t - Generate golang source code from k6 extension's API definition.\n* [tygor parse](#tygor-parse)\t - Convert k6 extension's API definition to JSON data model.\n\n---\n## tygor doc\n\nGenerate documentation from k6 extension's API definition.\n\n### Synopsis\n\nFrom the TypeScript declaration file, tygor doc subcommand generates API documentation.\n\nAPI documentation is generated to standard output in Markdown format by default. If the --html flag is used, the output format will be HTML.\n\nThe output can also be saved to a file using the --output flag. In this case, the default format is determined from the file extension: in the case of .htm and .html extensions, it will be in HTML format, otherwise it will be in Markdown format. Using the --html flag, the HTML format can also be forced for other file extensions.\n\nAPI documentation can also be inserted (and updated) into an existing Markdown or HTML document using the --inject flag. The insertion takes place in the place marked by so-called marker comments:\n\n    \u003c!-- begin:api --\u003e\n    generated API documentation goes here\n    \u003c!-- end:api --\u003e\n\nThe generated API documentation starts at heading level 1 by default. The starting heading level can be specified by using the --heading flag, which can be useful, for example, when inserting into an outer document.\n\nThe documentation may include the usual extension documentation sections, such as build instructions, download instructions, a link to the examples folder, etc. The required GitHub repository can be specified using the --github-repo flag. Otherwise, the tygor doc subcommand tries to guess the GitHub repository from the git configuration (if it exists). This automation can be disabled with the --no-auto flag.\nBy default, GitHub repository and generateable boilerplate sections are automatically detected. This is done by examining the git configuration, the GitHub workflows configuration, and the examples directory.\n\nThe only mandatory argument to the doc subcommand is the name of the declaration file (which file name must end with a .d.ts suffix).\n\n\n```\ntygor doc file [flags]\n```\n\n### Examples\n\n```\n$ tygor doc -o README.md hitchhiker.d.ts\n```\n\n### Options\n\n```\n      --github-repo string   GitHub repository (owner/name)\n      --heading uint         initial heading level (default 1)\n  -h, --help                 help for doc\n      --html                 enable HTML output (default: based on file ext)\n  -i, --inject string        inject into outer file\n      --link-examples        enable examples folder link\n      --link-packages        enable GitHub container packages link\n      --link-releases        enable GitHub releases link\n      --no-auto              disable automatic GitHub repo and link flags detection\n  -o, --output string        output file (default: standard output)\n  -t, --template string      go template file for markdown generation\n```\n\n### SEE ALSO\n\n* [tygor](#tygor)\t - CLI tool that enables the development of k6 extensions with an API-First approach.\n\n---\n## tygor gen\n\nGenerate golang source code from k6 extension's API definition.\n\n### Synopsis\n\nFrom the TypeScript declaration file, tygor gen subcommand generates the go interfaces needed to implement the API, as well as the binding code between the go implementation and the JavaScript runtime. In addition, tygor gen subcommand is also able to generate a skeleton implementation to help create a go implementation.\n\nThe skeleton file can be used as a sample for the implementation. Since it contains a special go build tag (//go:build skeleton), its presence will not interfere with the real implementation. To start the implementation, simply copy the skeleton file under a different name (or rename it) and delete the comments at the beginning of the file. If the declaration file changes, the bindings and skeleton can be regenerated at any time, and the skeleton can be used to help implement the changes.\n\nThe only mandatory argument is the name of the declaration file (which file name must end with a .d.ts suffix).\n\n\n```\ntygor gen file [flags]\n```\n\n### Examples\n\n```\n$ tygor gen --skeleton hitchhiker.d.ts\n```\n\n### Options\n\n```\n  -h, --help             help for gen\n  -o, --output string    output directory (default: same as input)\n  -p, --package string   go package name (default: module name)\n  -s, --skeleton         enable skeleton generation (default: disabled)\n```\n\n### SEE ALSO\n\n* [tygor](#tygor)\t - CLI tool that enables the development of k6 extensions with an API-First approach.\n\n---\n## tygor help\n\nHelp about any command\n\n### Synopsis\n\nHelp provides help for any command in the application.\nSimply type tygor help [path to command] for full details.\n\n```\ntygor help [command] [flags]\n```\n\n### Options\n\n```\n  -h, --help   help for help\n```\n\n### SEE ALSO\n\n* [tygor](#tygor)\t - CLI tool that enables the development of k6 extensions with an API-First approach.\n\n---\n## tygor parse\n\nConvert k6 extension's API definition to JSON data model.\n\n### Synopsis\n\nFrom the TypeScript declaration file,  tygor parse subcommand generates the API model in JSON format. The API model can be processed by external programs without the complexity of TypeScript parsing.\n\nThe only mandatory argument of the tygor parse subcommand is the name of the declaration file (which file name must end with a .d.ts suffix).\t\t\n\n\n```\ntygor parse file [flags]\n```\n\n### Examples\n\n```\n$ tygor parse hitchhiker.d.ts | jq\n```\n\n### Options\n\n```\n  -h, --help            help for parse\n  -o, --output string   output file (default: standard output)\n```\n\n### SEE ALSO\n\n* [tygor](#tygor)\t - CLI tool that enables the development of k6 extensions with an API-First approach.\n\n\u003c!-- end:cli --\u003e\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fszkiba%2Ftygor","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fszkiba%2Ftygor","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fszkiba%2Ftygor/lists"}