@nebius/js-sdk - v0.2.54
    Preparing search index...

    Interface FileOptions

    =================================================================== Options

    Each of the definitions above may have "options" attached. These are just annotations which may cause code to be generated slightly differently or may contain hints for code that manipulates protocol messages.

    Clients may define custom options as extensions of the *Options messages. These extensions may not yet be known at parsing time, so the parser cannot store the values in them. Instead it stores them in a field in the *Options message called uninterpreted_option. This field must have the same name across all *Options messages. We then use this field to populate the extensions when we build a descriptor, at which point all protos have been parsed and so all extensions are known.

    Extension numbers for custom options may be chosen as follows:

    • For options which will only be used within a single application or organization, or for experimental options, use field numbers 50000 through 99999. It is up to you to ensure that you do not use the same number for multiple options.
    • For options which will be published and used publicly by multiple independent entities, e-mail protobuf-global-extension-registry@google.com to reserve extension numbers. Simply provide your project name (e.g. Objective-C plugin) and your project website (if available) -- there's no need to explain how you intend to use them. Usually you only need one extension number. You can declare multiple options with only one extension number by putting them in a sub-message. See the Custom Options section of the docs for examples: https://developers.google.com/protocol-buffers/docs/proto#options If this turns out to be popular, a web service will be set up to automatically assign option numbers.
    interface FileOptions {
        "[customJson]"?: () => unknown;
        "[unknownFieldsSymbol]"?: Uint8Array<ArrayBufferLike>;
        $type: "google.protobuf.FileOptions";
        ccEnableArenas?: boolean;
        ccGenericServices?: boolean;
        csharpNamespace?: string;
        deprecated?: boolean;
        features?: FeatureSet;
        fileDeprecationDetails?: DeprecationDetails;
        goPackage?: string;
        javaGenerateEqualsAndHash?: boolean;
        javaGenericServices?: boolean;
        javaMultipleFiles?: boolean;
        javaOuterClassname?: string;
        javaPackage?: string;
        javaStringCheckUtf8?: boolean;
        objcClassPrefix?: string;
        optimizeFor?: FileOptions_OptimizeMode;
        phpClassPrefix?: string;
        phpMetadataNamespace?: string;
        phpNamespace?: string;
        pyGenericServices?: boolean;
        rubyPackage?: string;
        swiftPrefix?: string;
        uninterpretedOption: UninterpretedOption[];
        [key: symbol]: Uint8Array<ArrayBufferLike> | (() => unknown) | undefined;
    }

    Indexable

    • [key: symbol]: Uint8Array<ArrayBufferLike> | (() => unknown) | undefined

      =================================================================== Options

      Each of the definitions above may have "options" attached. These are just annotations which may cause code to be generated slightly differently or may contain hints for code that manipulates protocol messages.

      Clients may define custom options as extensions of the *Options messages. These extensions may not yet be known at parsing time, so the parser cannot store the values in them. Instead it stores them in a field in the *Options message called uninterpreted_option. This field must have the same name across all *Options messages. We then use this field to populate the extensions when we build a descriptor, at which point all protos have been parsed and so all extensions are known.

      Extension numbers for custom options may be chosen as follows:

      • For options which will only be used within a single application or organization, or for experimental options, use field numbers 50000 through 99999. It is up to you to ensure that you do not use the same number for multiple options.
      • For options which will be published and used publicly by multiple independent entities, e-mail protobuf-global-extension-registry@google.com to reserve extension numbers. Simply provide your project name (e.g. Objective-C plugin) and your project website (if available) -- there's no need to explain how you intend to use them. Usually you only need one extension number. You can declare multiple options with only one extension number by putting them in a sub-message. See the Custom Options section of the docs for examples: https://developers.google.com/protocol-buffers/docs/proto#options If this turns out to be popular, a web service will be set up to automatically assign option numbers.
      • Uint8Array<ArrayBufferLike>
      • () => unknown
          • (): unknown

          • =================================================================== Options

            Each of the definitions above may have "options" attached. These are just annotations which may cause code to be generated slightly differently or may contain hints for code that manipulates protocol messages.

            Clients may define custom options as extensions of the *Options messages. These extensions may not yet be known at parsing time, so the parser cannot store the values in them. Instead it stores them in a field in the *Options message called uninterpreted_option. This field must have the same name across all *Options messages. We then use this field to populate the extensions when we build a descriptor, at which point all protos have been parsed and so all extensions are known.

            Extension numbers for custom options may be chosen as follows:

            • For options which will only be used within a single application or organization, or for experimental options, use field numbers 50000 through 99999. It is up to you to ensure that you do not use the same number for multiple options.
            • For options which will be published and used publicly by multiple independent entities, e-mail protobuf-global-extension-registry@google.com to reserve extension numbers. Simply provide your project name (e.g. Objective-C plugin) and your project website (if available) -- there's no need to explain how you intend to use them. Usually you only need one extension number. You can declare multiple options with only one extension number by putting them in a sub-message. See the Custom Options section of the docs for examples: https://developers.google.com/protocol-buffers/docs/proto#options If this turns out to be popular, a web service will be set up to automatically assign option numbers.

            Returns unknown

      • undefined
    Index
    [customJson]? [unknownFieldsSymbol]? $type ccEnableArenas? ccGenericServices? csharpNamespace? deprecated? features? fileDeprecationDetails? goPackage? javaGenerateEqualsAndHash? javaGenericServices? javaMultipleFiles? javaOuterClassname? javaPackage? javaStringCheckUtf8? objcClassPrefix? optimizeFor? phpClassPrefix? phpMetadataNamespace? phpNamespace? pyGenericServices? rubyPackage? swiftPrefix? uninterpretedOption
    "[customJson]"?: () => unknown

    Returns a safe value for JSON logs.

    Type Declaration

      • (): unknown

      • Returns a safe value for JSON logs.

        Returns unknown

    "[unknownFieldsSymbol]"?: Uint8Array<ArrayBufferLike>

    Preserves protobuf fields that this SDK version does not recognize.

    $type: "google.protobuf.FileOptions"

    Contains the fully qualified protobuf type name.

    ccEnableArenas?: boolean

    Enables the use of arenas for the proto messages in this file. This applies only to generated classes for C++.

    ccGenericServices?: boolean

    Should generic services be generated in each language? "Generic" services are not specific to any particular RPC system. They are generated by the main code generators in each language (without additional plugins). Generic services were the only kind of service generation supported by early versions of google.protobuf.

    Generic services are now considered deprecated in favor of using plugins that generate code specific to your particular RPC system. Therefore, these default to false. Old code which depends on generic services should explicitly set them to true.

    csharpNamespace?: string

    Namespace for generated classes; defaults to the package.

    deprecated?: boolean

    Is this file deprecated? Depending on the target platform, this can emit Deprecated annotations for everything in the file, or it will be completely ignored; in the very least, this is a formalization for deprecating files.

    features?: FeatureSet

    Any features defined in the specific edition. WARNING: This field should only be used by protobuf plugins or special cases like the proto compiler. Other uses are discouraged and developers should rely on the protoreflect APIs for their client language.

    fileDeprecationDetails?: DeprecationDetails

    Contains the file deprecation details.

    goPackage?: string

    Sets the Go package where structs generated from this .proto will be placed. If omitted, the Go package will be derived from the following:

    • The basename of the package import path, if provided.
    • Otherwise, the package statement in the .proto file, if present.
    • Otherwise, the basename of the .proto file, without extension.
    javaGenerateEqualsAndHash?: boolean

    This option does nothing.

    Deprecated.

    javaGenericServices?: boolean

    Contains the java_generic_services protobuf field.

    javaMultipleFiles?: boolean

    If enabled, then the Java code generator will generate a separate .java file for each top-level message, enum, and service defined in the .proto file. Thus, these types will not be nested inside the wrapper class named by java_outer_classname. However, the wrapper class will still be generated to contain the file's getDescriptor() method as well as any top-level extensions defined in the file.

    javaOuterClassname?: string

    Controls the name of the wrapper Java class generated for the .proto file. That class will always contain the .proto file's getDescriptor() method as well as any top-level extensions defined in the .proto file. If java_multiple_files is disabled, then all the other classes from the .proto file will be nested inside the single wrapper outer class.

    javaPackage?: string

    Sets the Java package where classes generated from this .proto will be placed. By default, the proto package is used, but this is often inappropriate because proto packages do not normally start with backwards domain names.

    javaStringCheckUtf8?: boolean

    A proto2 file can set this to true to opt in to UTF-8 checking for Java, which will throw an exception if invalid UTF-8 is parsed from the wire or assigned to a string field.

    TODO: clarify exactly what kinds of field types this option applies to, and update these docs accordingly.

    Proto3 files already perform these checks. Setting the option explicitly to false has no effect: it cannot be used to opt proto3 files out of UTF-8 checks.

    objcClassPrefix?: string

    Sets the objective c class prefix which is prepended to all objective c generated classes from this .proto. There is no default.

    optimizeFor?: FileOptions_OptimizeMode

    Contains the optimize_for protobuf field.

    phpClassPrefix?: string

    Sets the php class prefix which is prepended to all php generated classes from this .proto. Default is empty.

    phpMetadataNamespace?: string

    Use this option to change the namespace of php generated metadata classes. Default is empty. When this option is empty, the proto file name will be used for determining the namespace.

    phpNamespace?: string

    Use this option to change the namespace of php generated classes. Default is empty. When this option is empty, the package name will be used for determining the namespace.

    pyGenericServices?: boolean

    Contains the py_generic_services protobuf field.

    rubyPackage?: string

    Use this option to change the package of ruby generated classes. Default is empty. When this option is not set, the package name will be used for determining the ruby package.

    swiftPrefix?: string

    By default Swift generators will take the proto package and CamelCase it replacing '.' with underscore and use that to prefix the types/symbols defined. When this options is provided, they will use this value instead to prefix the types/symbols defined.

    uninterpretedOption: UninterpretedOption[]

    The parser stores options it doesn't recognize here. See the documentation for the "Options" section above.

    Settings
    Member Visibility

    On This Page
    Properties