Skip to main content

SDK language options

The language options are used to customize the SDK generation on a per-SDK language basis.

Generic language options​

These options are applicable to all SDK languages, and are set on a per-language basis in the specific SDK language section. For example, the sdkVersion can be set to different values for each language SDK:

{
    ...
    "languageOptions": {
        "typescript": {
            "sdkVersion": "1.0.0-alpha"
        },
        "python": {
            "sdkVersion": "1.0.0-beta"
        },
        "java": {
            "sdkVersion": "1.0.0-beta-2"
        }
    }
    ...
}
OptionTypeRequiredDefaultDescription
liblabVersionstring❌language dependantThe version of liblab SDK generation to use
githubRepoNamestring❌N/AThe name of the GitHub repository for the SDK
targetBranchstring❌mainThe branch to create the pull request against
ignoreFilesarray❌N/AA list of files to ignore when generating the SDK
sdkVersionstring❌N/AThe version of the SDK
hookDependenciesarray❌N/AAdditional dependencies for hooks
authorsarray❌N/AThe authors of the SDK. These values are added to the relevant package manifest. This is not supported for Java SDKs
homepagestring❌N/AThe URL for the homepage for this SDK. This is added to the relevant package manifest
additionalConstructorParametersarray❌[]Additional parameters to add to the SDK client constructor. These parameters can then be accessed in hooks.

liblabVersion​

Supported SDK languages and versions:

TypeScript v1TypeScript v2Java v1Java v2Python v1Python v2C#GoPHP
✅✅✅✅✅✅✅✅✅

The liblabVersion setting sets the version of the liblab SDK generation to use.

For example, to use v2 of liblab to generate a Python SDK, use the following:

{
    "languages": [
        "python"
    ],
    "languageOptions": {
        "python": {
            "liblabVersion": "2"
        }
    }
}

The default value of this option depends on the SDK language. These default versions, along with the available versions are documented in our liblab version guide.

Some SDK languages are only available in certain versions of liblab, whereas others might be available in multiple versions and you can use this option to determine which version to use.

If an SDK language is added in a later version, then setting an earlier version will default to the first version that supports that language. For example, C# is added in liblab version 2, so setting this to 1:

{
    "languages": [
        "csharp"
    ],
    "languageOptions": {
        "csharp": {
            "liblabVersion": "1"
        }
    }
}

Will be the equivalent of setting it to 2.

You can read more on the supported liblab versions and the capabilities of SDKs using these versions in our liblab version guide.

githubRepoName​

Supported SDK languages and versions:

TypeScript v1TypeScript v2Java v1Java v2Python v1Python v2C#GoPHP
✅✅✅✅✅✅✅✅✅

The githubRepoName setting sets the name of the GitHub repository for this SDK. This is used by the liblab pr command to create a pull request for the SDK into that repo. You can read more about this in the liblab pr section of the liblab CLI documentation.

targetBranch​

Supported SDK languages and versions:

TypeScript v1TypeScript v2Java v1Java v2Python v1Python v2C#GoPHP
✅✅✅✅✅✅✅✅✅

The targetBranch setting sets the branch in GitHub for this SDK in the repo defined in the githubRepoName setting. This is used by the liblab pr command to create a pull request for the SDK into that branch. You can read more about this in the liblab pr section of the liblab CLI documentation.

ignoreFiles​

Supported SDK languages and versions:

TypeScript v1TypeScript v2Java v1Java v2Python v1Python v2C#GoPHP
✅✅✅✅✅✅✅✅✅

This option allows you to specify a list of files to ignore when generating the SDK. This is useful if you want to exclude files that are generated by the SDK generator. For example, if you want to completely customize the README or package manifest files.

For example, if you want to create a custom README file for your SDK that is not replaced during SDK generation, set this value to README.md:

{
    ...
    "languageOptions": {
        "typescript": {
            "ignoreFiles": [
                "README.md"
            ]
        }
    }
    ...
}

This is an array, so you can specify as many files as you need.

sdkVersion​

Supported SDK languages and versions:

TypeScript v1TypeScript v2Java v1Java v2Python v1Python v2C#GoPHP
✅✅✅✅✅✅✅❌1❌

1 Go does not have a package manifest file for this version to be written to. This version is written to the README.md file, and you will need to manually use it when you create a release of your SDK inside you GitHub repository.

The sdkVersion setting sets the version of the SDK in the relevant file. For example, for Python SDKs, this is set in the pyproject.toml file, for TypeScript this is set in the project.json file.

This version should be using semver to ensure it is compatible with the different package managers. TypeScript has some limitations on what is supported, so any labels (such as alpha in 0.9.3-alpha) will be stripped out.

For example, with these options:

{
    ...
    "languageOptions": {
        "typescript": {
            "sdkVersion": "1.0.0-alpha"
        }
    }
    ...
}

The TypeScript project.json file will look like:

{
    "version": "1.0.0"
}

Whereas the Python pyproject.toml file will look like:

[project]
version = "1.0.0-alpha"

hookDependencies​

Supported SDK languages and versions:

TypeScript v1TypeScript v2Java v1Java v2Python v1Python v2C#GoPHP
✅❌✅❌✅✅❌❌✅

When you create hooks, you can define the dependencies for those hooks in the relevant hooks folder (such as in the requirements.txt for Python hooks). If you need to add additional dependencies, you can add them here and they will be added to the SDKs.

note

This should only be used if there is a reason you cannot add the dependency to the hook code directly. It is best practice to add them there.

This is an array of objects, with each object having the following options:

OptionTypeRequiredDefaultDescription
namestring✅N/AThe name of the dependency
versionstring✅N/AThe version of the dependency
groupIdstring❌N/AThe groupId of the hook dependency for Java hooks

name​

The name field is the name of the package that needs to be included in the dependencies. This is the same name you would use with the relevant packaging tool to install the package, such as npm install or pip install.

For example, to include the Python python-dotenv package, you would use:

{
  ...
  "languageOptions": {
    "python": {
      "hookDependencies": [
        {
          "name": "python-dotenv",
          "version": "1.0.0"
        }
      ]
    }
  }
  ...
}

version​

The version field defines the version to add to the dependencies.

For example, to include the TypeScript pad-left package fixed at version 1.0.2 you would use:

{
  ...
  "languageOptions": {
    "typescript": {
      "hookDependencies": [
        {
          "name": "pad-left",
          "version": "1.0.2"
        }
      ]
    }
  }
  ...
}

groupId​

The groupId setting is used for Java packages only, and allows you to define the groupId for the hook dependency.

authors​

Supported SDK languages and versions:

TypeScript v1TypeScript v2Java v1Java v2Python v1Python v2C#GoPHP
✅❌❌❌✅❌✅❌❌

The authors option sets the list of authors of the SDK in the relevant package manifest. This is an array of objects containing the authors name, and optionally their email.

The author is set in the package.json file in the SDK.

For example, setting:

{
    ...
    "languageOptions": {
        "typescript": {
            "authors": [
                {
                    "name": "Llama Soda",
                    "email": "llama.soda@exciting.soda"
                }
            ]
        }
    }
    ...
}

will give a package.json file with:

{
    ...
    "author": "Llama Soda <llama.soda@exciting.soda>",
    ...
}
note

Only one author is supported for TypeScript. If you set multiple authors for TypeScript, only the first one is used.

OptionTypeRequiredDefaultDescription
namestring✅N/AThe name of the author
emailstring❌N/AThe email address of the author

name​

The name field is the name of the author.

email​

The email field defines the email address of the author. This field is optional.

homepage​

Supported SDK languages and versions:

TypeScript v1TypeScript v2Java v1Java v2Python v1Python v2C#GoPHP
✅✅✅✅✅❌✅❌❌

The homepage option sets the homepage of the SDK in the relevant package manifest. This needs to be a valid URL.

The homepage is set in the package.json file in the SDK. For example, setting:

{
    ...
    "languageOptions": {
        "typescript": {
            "homepage": "https://exciting.soda"
        }
    }
    ...
}

will give a package.json file with:

{
    ...
    "homepage": "https://exciting.soda",
    ...
}

additionalConstructorParameters​

Supported SDK languages and versions:

TypeScript v1TypeScript v2JavaPython v1Python v2C#GoPHP
❌❌❌❌✅❌✅❌

The additionalConstructorParameters option allows you to specify additional parameters that will be added to the SDK client constructor. These parameters can then be accessed from hooks.

This is an array of objects, with each object having the following properties:

OptionTypeRequiredDefaultDescription
namestring✅N/AThe name of the parameter
examplestring❌N/AAn example value for the generated documentation

These parameters will be added to the SDK client constructor either directly, or via a config object depending on the SDK language.

Additional constructor parameters are not supported in v1 of the TypeScript SDK generation.

C# specific options​

These options are specific to the C# SDKs.

OptionTypeRequiredDefaultDescription
packageIdstring❌N/AThe NuGet package Id to set for the C# SDK project

packageId​

The packageId setting sets the NuGet package Id that will be used for the generated SDK project. This will be used as the package identifier that is used across the relevant NuGet gallery.

For example, with this option:

{
    ...
    "languageOptions": {
        "csharp": {
            "packageId": "Exciting.Soda"
        }
    }
    ...
}

You will get a .csproj file with the package Id set like this:

<PropertyGroup>
  <PackageId>Exciting.Soda</PackageId>
</PropertyGroup>

Go specific options​

These options are specific to the Go SDKs.

OptionTypeRequiredDefaultDescription
goModuleNamestring✅N/AThe Go module to use for the SDK

goModuleName​

The goModuleName setting sets the Go module to use for the SDK. This is set in the go.mod file, and is used when publishing the SDK to Go.

For example, with these options:

{
    ...
    "languageOptions": {
        "go": {
            "goModuleName": "github.com/excitingsoda/sdk"
        }
    }
    ...
}

You will get a go.mod file that looks like:

module github.com/excitingsoda/sdk

This should conform to the Go module naming rules.

note

If you are generating a Terraform provider, you will also need to set this value regardless of whether you are also generating a Go SDK. The Terraform provider contains an internal Go SDK used to interact with your API that needs this module name. This value must be different than the Terraform provider's providerGoModuleName option.

Java specific options​

These options are specific to the Java SDKs.

OptionTypeRequiredDefaultDescription
groupIdstring❌N/AThe Maven group ID to use for the SDK

groupId​

The groupId is used to set the groupId used by the Java SDK. This is set as the groupId in the pom.xml file, as well as being used to define the namespace for the SDK classes.

For example, with these options:

{
    ...
    "languageOptions": {
        "java": {
            "groupId": "soda.exciting"
        }
    }
    ...
}

You would get this in the pom.xml file:

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" 
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <groupId>soda.exciting</groupId>
  ...
</project>

The package name for the SDK would be soda.exciting. In the output folder you would have src/main/java/soda/exciting, and the classes would be in the soda.exciting namespace:

package soda.exciting;

If this is not set, the groupId will default to either the baseURL if this is set, or to the first entry in the servers list in the spec in reverse domain format.

note

If you also release other Java packages then it is recommended that you set the groupId to a specific Id for this SDK instead of just relying on the baseURL or servers list. This will reduce the chance of your customers having clashes with split packages.

PHP specific options​

These options are specific to the PHP SDKs.

OptionTypeRequiredDefaultDescription
packageNamestring✅N/AThe name of the Composer package to publish to

packageName​

The packageName setting sets the name of the Composer package. This is set in the composer.json file, and is used when publishing the SDK to PHP repositories like Packagist.

It must be in the format vendor/package, where vendor is the name of your organization (e.g. exciting-soda), and package is the name of the package (e.g. sdk). It must not have any spaces or capital letters. For example, with these options:

json
{
    ...
    "languageOptions": {
        "php": {
            "packageName": "exciting-soda/sdk"
        }
    }
    ...
}

You will get a composer.json file that looks like:

json
{
    "name": "exciting-soda/sdk",
    ...
}

Python specific options​

These options are specific to the Python SDKs.

OptionTypeRequiredDefaultDescription
pypiPackageNamestring❌N/AThe name of the PyPI package to publish to
alwaysInitializeOptionalsbool❌trueShould optional parameters always be initialized?
classifiersarray❌trueThe classifiers to set in the pyproject.toml
projectUrlsobject❌trueA list of project URLs to add to the pyproject.toml file
strictVersionbool❌falseEnforce strict dependency versions be generated
enforceRequestValidationbool❌false(v1), true(v2)If requests are sent as dictionaries instead of models, should they be validated for all mandatory fields

pypiPackageName​

Supported Python SDK generation versions:

Python v1Python v2
✅✅

The pypiPackageName setting sets the name of the PyPI package to publish to. This is set in the pyproject.toml file, and is used when publishing the SDK to PyPI.

For example, with these options:

{
    ...
    "languageOptions": {
        "python": {
            "pypiPackageName": "exciting-soda"
        }
    }
    ...
}

You will get a pyproject.toml file that looks like:

[project]
name = "exciting-soda"

alwaysInitializeOptionals​

Supported Python SDK generation versions:

Python v1Python v2
✅✅

By default, optional parameters that are not set on a request object, or received on a response object are set to None. This is the default behavior for Python, and is the recommended way to handle optional parameters. If you have a reason for not initializing anything that is not set, then set this option to false.

For example, if this is set to true (the default), a request object will look something like this:

class SodaRequest(BaseModel):
  def __init__(
    self,
    id: int,
    name: str = None,
    flavor: str = None,
    **kwargs,
  ):
    self.id = id

    self.name = name
    self.flavor = flavor

If this is set to false, you would get:

class SodaRequest(BaseModel):
  def __init__(
    self,
    id: int,
    name: str = None,
    flavor: str = None,
    **kwargs,
  ):
    self.id = id

    if name is not None:
      self.name = name
    if flavor is not None:
      self.flavor = flavor

This may be preferred depending on what your API is expecting.

classifiers​

Supported Python SDK generation versions:

Python v1Python v2
✅✅

The classifiers setting sets the PyPI Trove classifiers that will be set in the pyproject.toml file. This is an array of strings, with each string being a classifier that will be added.

For example, setting this:

{
    ...
    "languageOptions": {
        "python": {
            "classifiers": [
                "Development Status :: 3 - Alpha",
                "Programming Language :: Python :: 3.9"
            ]
        }
    }
    ...
}

Will give a pyproject.toml file that looks like:

[project]
classifiers = [
  "Development Status :: 3 - Alpha",
  "Programming Language :: Python :: 3.9"
]
...

projectUrls​

Supported Python SDK generation versions:

Python v1Python v2
❌✅

The projectUrls setting sets the URLs for the project in the pyproject.toml file. This is an object, with each key being the name of the URL, and the value being the URL itself.

For example, setting this:

{
    ...
    "languageOptions": {
        "python": {
            "projectUrls": {
                "Homepage": "https://exciting.soda",
                "Documentation": "https://exciting.soda/docs"
            }
        }
    }
    ...
}

Will give a pyproject.toml file that looks like:

[project.urls]
Homepage = "https://exciting.soda"
Documentation = "https://exciting.soda/docs"

strictVersion​

Supported Python SDK generation versions:

Python v1Python v2
✅❌

The strictVersion setting sets whether or not to enforce strict dependency versions in the generated requirements.txt (Python v1) and pyproject.toml (Python v1 and v2) files. If this is set to true, then the SDK will use the exact version of the dependency. If this is set to false, then the SDK will use the minimum version of the dependency.

This applies to both the dependencies from the generated SDK, and any dependencies set in any custom hooks you have written.

For example, if this is set to false, or not set, then the generated dependency files will look like this:

requests
http-exceptions
pytest
responses

If this is set to true, then the generated files will have the versions set:

requests==2.31.0
http-exceptions==0.2.10
pytest==7.1.2
responses==0.21.0
note

From v2 onwards, liblab will only generate a pyproject.toml file and not a requirements.txt file.

enforceRequestValidation​

Supported Python SDK generation versions:

Python v1Python v2
✅✅

When a Python SDK is generated, models are created for the requests and responses made, providing strong typing for your API. Python SDKs also support passing dictionaries instead of models. If a dictionary is passed, the enforceRequestValidation flag determines if that dictionary is validated against the expected properties for the request in the SDK, or if it is left to the API.

For SDKs generated using Python v1 (liblabVersion set to "1), the default value is false. For SDKs generated using Python v2 (liblabVersion set to "2), the default value is true.

Setting enforceRequestValidation to true will validate in the SDK, setting it to false will not.

For example, if you have the following schema in you spec:

MessageRequest:
  type: object
  properties:
    name:
      type: string
      description: The message name
    content:
      type: string
      description: The contents of the message.
  required:
    - name
    - content

A MessageRequest object will be generated in the SDK:

class MessageRequest(BaseModel):
    def __init__(self, content: str, name: str, **kwargs):
        self.content= content
        self.name= name

When you call the SDK, you can either pass this request object:

request = MessageRequest(name="Greeting", content="This soda is exciting!")
message_service.create_message(request)

Or you can pass a dictionary:

request = {"name":"Greeting", "content":"This soda is exciting!"}
message_service.create_message(request)

If you pass a dictionary, then it is easier to make a mistake and not pass the required properties. For example, in this case you might set the "message" property instead of "content":

# message is the wrong property name, it should be content
request = {"name":"Greeting", "message":"This soda is exciting!"}
message_service.create_message(request)

If enforceRequestValidation is set to true and you pass this dictionary, then the SDK will create a MessageRequest for you from the dictionary values, and raise an exception if any required properties are missing:

TypeError: MessageRequest.__init__() got an unexpected keyword argument 'message'

If enforceRequestValidation is set to false then the dictionary is passed to the API as is, and the API will need to validate the data.

Only required properties are validated.

Terraform specific options​

These options are specific to Terraform providers.

OptionTypeRequiredDefaultDescription
providerNamestring✅N/AThe name of the Terraform provider. This must be in kebab-case.
providerVersionstring✅N/AThe version of the Terraform provider. This must be in semver format.
providerGoModuleNamestring✅N/AThe name of the Go module to use for the Terraform provider.
providerSchemaConfigobject❌
{
   "addressKey": "host",
   "authTokenKey": "auth_token"
}
Customization for keys in the Terraform provider configuration.
mockAcceptancebool❌falseShould the generated Terraform provider tests use a mock server or not?
hideComputedDiffbool❌falseHide computed values on updates

providerName​

This is the name of the Terraform provider, and must be in kebab-case.

For example, with these options:

{
    ...
    "languageOptions": {
        "terraform": {
            "providerName": "exciting-soda-provider",
        }
    }
    ...
}

You will get a provider.go file that contains the following:

func (p *Provider) Metadata(ctx context.Context,
                            req provider.MetadataRequest,
                            resp *provider.MetadataResponse) {
    resp.TypeName = "exciting-soda-provider"
    ...
}

Which will result in your end customers main.tf:

provider "exciting-soda-provider" {
  host = "https://api.soda.com"
  auth_token = "soda_MyToken123"
}

providerVersion​

This is the version of the Terraform provider, and must be in semver format.

For example, with these options:

{
    ...
    "languageOptions": {
        "terraform": {
            "providerVersion": "1.7.2"
        }
    }
    ...
}

You will get a provider.go file that contains the following:

func (p *Provider) Metadata(ctx context.Context, 
                            req provider.MetadataRequest, 
                            resp *provider.MetadataResponse) {
    resp.Version = "1.7.2"
    ...
}

Which will result in your end customers main.tf:

terraform {
  required_providers {
    exciting-soda = {
      source  = "hashicorp.com/exciting-soda"
      version = "1.7.2"
    }
  }
}

providerGoModuleName​

This is the name of the Go module to use for the Terraform provider. This is set in the go.mod file, and is used when publishing the Terraform provider.

For example, with these options:

{
    ...
    "languageOptions": {
        "terraform": {
            "providerGoModuleName": "github.com/excitingsoda/provider"
        }
    }
    ...
}

You will get a go.mod file in your Terraform provider that looks like:

module github.com/excitingsoda/provider

This should conform to the Go module naming rules, and must be different to the goModuleName option in the Go language options.

note

The Terraform provider is a Go module that wraps an internal Go SDK used to interact with your API. This means that you will need to set the goModuleName option for the Go SDK as well as the providerGoModuleName option for the Terraform provider. These 2 values must be different.

providerSchemaConfig​

This option provides options to customize how your Terraform provider schema is generated. This is an object with the following options:

OptionTypeRequiredDefaultDescription
addressKeystring❌hostThe key to use for the server url field in the provider schema
authTokenKeystring❌auth_tokenThe key to use for the auth token field in the provider schema

For example, with these options:

{
    ...
    "languageOptions": {
        "terraform": {
            "providerSchemaConfig": {
                "addressKey": "url",
                "authTokenKey": "token"
            }
        }
    }
    ...
}

The generated provider schema will look like this:

func (p *Provider) Schema(ctx context.Context, req provider.SchemaRequest, resp *provider.SchemaResponse) {
    resp.Schema = schema.Schema{
        Attributes: map[string]schema.Attribute{
            "url": schema.StringAttribute{
                ...
            },
            "token": schema.StringAttribute{
                ...
            },
        },
    }
}

Which will result in your end customers main.tf:

provider "exciting-soda" {
    url = "https://api.soda.com"
    token = "soda_MyToken"
}

Since this is an optional field - you can omit it. The default behavior is:

provider "exciting-soda" {
    host = "https://api.soda.com"
    auth_token = "soda_MyToken"
}

mockAcceptance​

When a Terraform provider is generated, liblab will also generate end-to-end acceptance tests for the provider. These tests will call your API to ensure that the provider is working as expected.

The mockAcceptance setting determines whether or not to use a mock server for the Terraform provider acceptance tests. If this is set to true, then a mock server will be used. If this is set to false, then the actual API will be used.

hideComputedDiff​

When generating a plan for a resource, there will be values that are computed on the server (e.g. id or createdAt). Terraform shows the following value on terraform plan in such cases, for example id = (known after apply).

When generating a plan for updates, setting this value to true hides the computed values in the update.

This does not apply to create, when all computed values are required to be shown.

warning

Some computed values are computed even on updates (e.g. updateAt). Setting this flag to true will cause errors when generating the plan. If you have such fields, please mark them with x-liblab-show-diff: true.

TypeScript specific options​

These options are specific to the TypeScript SDKs.

OptionTypeRequiredDefaultDescription
npmOrgstring❌N/AThe npm organization to publish to
npmNamestring❌N/AThe npm package name to publish to
httpClientstring❌axiosThe HTTP client to use
bundlebool❌falseShould the SDKs be bundled
exportClassDefaultbool❌falseShould the SDK export the main class as default

npmOrg​

Supported TypeScript SDK generation versions:

TypeScript v1TypeScript v2
✅❌

The npmOrg setting sets the scope for the npm package name.

For example, with these options:

{
    ...
    "languageOptions": {
        "typescript": {
            "npmOrg": "exciting",
            "npmName": "soda"
        }
    }
    ...
}

You will get a package.json file that looks like:

{
    "name": "@exciting/soda",
    ...
}

Set this to your organization name if you want to publish the SDK to your organization's npm account.

npmName​

Supported TypeScript SDK generation versions:

TypeScript v1TypeScript v2
✅❌

The npmName setting sets the npm package name, scoped with the npmOrg if this is set. For example6, if you set the npmOrg to exciting, and the npmName to soda, the SDK will be published to @exciting/soda.

Set this to your package name if you want to publish the SDK to your npm account.

httpClient​

Supported TypeScript SDK generation versions:

TypeScript v1TypeScript v2
✅❌

Sets the HTTP client to use for the SDK. This setting allows you to choose between Axios, Fetch, or the Node HTTPS module, depending on your preference or requirements.

Valid values are:

ValueDescription
axiosUse the Axios HTTP client
fetchUse the Fetch HTTP client
httpsUse the Node HTTPS module

If this value is not set, the axios client is used.

bundle​

Supported TypeScript SDK generation versions:

TypeScript v1TypeScript v2
✅❌

Setting the bundle option to true will configure the TypeScript SDK so that it can be bundled using tsup.

{
    ...
    "languageOptions": {
        "typescript": {
            "bundle": true
        }
    }
    ...
}

If this value is not set, it will default to false and not configure the SDK for bundling.

To bundle the SDK, once it has been created run the following commands from the output/typescript folder:

npm install
npm run build

This will bundle the SDK, creating the bundles in the dist folder. 2 bundles are created:

BundleDescription
index.cjsThe SDK bundled as a CommonJS module
index.jsThe SDK bundled as an ES Module

exportClassDefault​

Supported TypeScript SDK generation versions:

TypeScript v1TypeScript v2
✅❌

The exportClassDefault setting determines whether or not the SDK exports the main class as default. If this is set to true, then the SDK will export the main class as default. For example, if you have an SDK called Exciting-Soda, you can import it using:

import ExcitingSoda from 'excitingsoda';

If this is set to false, then the SDK will export the main class as a named export, and you import it using:

import { ExcitingSoda } from 'excitingsoda';
Last updated on