v1.21.0

Compatibility Notes

• New generated OData clients yield more narrow types on the _keys, _keyFields and _allFields properties, that differ from older generated clients. Old clients are still supported but will be deprecated soon.
• Internal directory structure has changed. This is a breaking change for users that reference internal modules directly.

New Functionality

• Added experimental support for OData v4. All functionality related to OData v4 is subject to change.

Improvements

• OData client generator: Narrow the types of the generated properties _keys, _keyFields and _allFields to the correct types.

Fixed Issues

• Fix the OData client generator to avoid a compilation error when a complex type only contains complex types.
• Fix the dependency versions in the aggregator package generated by the OData client generator.

v1.20.1

Fixed Issues

• Fix the OData client generator to also parse definitions of OpenAPI files with version higher than 3.

v1.20.0

Compatibility Notes

• When executing and building requests with the generic http-client custom request configurations now take precedence over configurations resulting from the given destination. This applies to all http-client related functions: buildHttpRequest, addDestinationToRequestConfig, execute and executeHttpRequest.

New Functionality

• Support setting log levels for all loggers globally. Use setGlobalLogLevel('debug') for this. Log levels set individually still take precedence.

Improvements

• Increase the information shown on VDM generation and parallelize the file creation process.

Fixed Issues

• Fix logging of error messages that were logged as undefined before.
• Fix serialization of EDM type Int64 to return a string instead of an instance of BigNumber.
• Fix JWT verification to use the url stored in the JKU field of the token's header to fetch the verification key.

v1.19.0

New Functionality

• Allow setting additional query parameters for OData queries, using withCustomQueryParameters().

v1.18.1

Compatibility Notes

• Due to the intoroduced validation for destination configurations, destinations of type HTTP are expected to contain a url or URL property. Note that when retrieving a destination from the destinations environment variable, all destinations are validated. This validation applies even to destinations that are not read.

Improvements

• Introduce validation for destinations retrieved from environment variable or destination service.
• Allow configuring the destinations environment variable with the same property keys as known from the destination service on SAP Cloud Platform, e.g. now URL is considered valid in addition to previously only url.

Fixed Issues

• Fix ordering for complex properties including nested complex properties.
• Fix the generator crashing for services containing function imports without a return type.
• Fix the destination processing so that the user can set PrincipalPropagation as authentication scheme for on-premises connectivity.

v1.18.0

Initial Release of the SAP Cloud SDK for JavaScript / TypeScript as Open Source project.

⚠️ If you have used previous versions of the SAP Cloud SDK, the package names have changed from @sap/cloud-sdk-<package> to @sap-cloud-sdk/<package>

Compatibility Notes

• Some packages of the SAP Cloud SDK for JavaScript have been migrated to external GitHub and are now available as open-source software.
  As a result, the packages have been renamed as shown in the list below.
  No Breaking changes are made.
  The old versions of the packages will not receive further updates, so we heavily encourage switching to the new version of the packages.
  • @sap/cloud-sdk-util was renamed to @sap-cloud-sdk/util
  • @sap/cloud-sdk-analytics was renamed to @sap-cloud-sdk/analytics
  • @sap/cloud-sdk-core was renamed to @sap-cloud-sdk/core
  • @sap/cloud-sdk-generator was renamed to @sap-cloud-sdk/generator
  • @sap/cloud-sdk-test-util was renamed to @sap-cloud-sdk/test-util

How to update your project

1. Search for all your dependencies/devDependencies/peerDependencies in your package.json.
2. Replace the old package name e.g., @sap/cloud-sdk-core with the new one, @sap-cloud-sdk/core.
3. Use the stable version of the open source version e.g., ^1.18.0.
4. Deleting your node_modules and the package-lock.json.
5. Install your dependencies again to reflect the changes via e.g., npm i.
6. Search for your source code that uses the old packages as import and replace it with new names.

Find more details in our quick migration guide

Improvements

• Allow the definition of a custom version for the generated package.json bypassing the desired version to the generator as an argument versionInPackageJson.

Versions prior to 1.18.0

Changelog

Find the changelog for versions prior to 1.18.0 here.