Deprecate External Usages Of CubiomesInternal

by ADMIN 46 views

Introduction

In the development of our app, we have been using the CubiomesInternal package to access specific types from the Cubiomes library. However, this approach has several drawbacks. Firstly, it creates a tight coupling between our app and the internal implementation details of the Cubiomes library. Secondly, it makes our code more prone to breaking changes when the library is updated. To address these issues, we propose to deprecate the external usage of CubiomesInternal and instead rely on the CubiomesKit package, which provides a more stable and maintainable interface to the Cubiomes library.

Rationale

The CubiomesInternal package is not intended to be used directly by external consumers of the Cubiomes library. Its primary purpose is to provide a low-level interface to the library's internal implementation details. By using this package, we are essentially bypassing the CubiomesKit package, which is the recommended way to access the Cubiomes library.

There are several reasons why we should avoid using CubiomesInternal:

  • Tight coupling: By using CubiomesInternal, we are tightly coupling our app to the internal implementation details of the Cubiomes library. This makes our code more prone to breaking changes when the library is updated.
  • Maintenance overhead: Using CubiomesInternal requires us to maintain a deep understanding of the library's internal implementation details. This can be a significant maintenance overhead, especially when the library is updated frequently.
  • Stability issues: The CubiomesInternal package is not designed to be stable or maintainable. Its API is subject to change without notice, which can break our app.

Proposed Solution

To address these issues, we propose to deprecate the external usage of CubiomesInternal and instead rely on the CubiomesKit package. The CubiomesKit package provides a more stable and maintainable interface to the Cubiomes library. It is designed to be used by external consumers of the library and provides a clear and well-documented API.

To make this transition smoother, we will need to:

  • Type-alias specific types: We will need to type-alias specific types from the CubiomesInternal package to make them available in the CubiomesKit package.
  • Add new structures: We may need to add new structures to the CubiomesKit package to allow for the same functionality as the CubiomesInternal package.
  • Add SwiftLint rules: We will need to add new SwiftLint rules to enforce the usage of CubiomesKit instead of CubiomesInternal.

Implementation Plan

To implement this proposal, we will follow these steps:

  1. Review the Cubiomes library: We will review the Cubiomes library to identify the specific types and structures that need to be type-aliased or added to the CubiomesKit package.
  2. Type-alias specific types: We will type-alias specific types from the CubiomesInternal package to make them available in the CubiomesKit package.
  3. Add new structures: We will add new structures to the CubiomesKit package to allow for the same functionality as the CubiomesInternal package.
  4. Add SwiftLint rules: We will add new SwiftLint rules to enforce the usage of CubiomesKit instead of CubiomesInternal.
  5. Test and verify: We will test and verify that the proposed solution works as expected and does not introduce any breaking changes.

Conclusion

Introduction

In our previous article, we discussed the proposal to deprecate the external usage of CubiomesInternal and instead rely on the CubiomesKit package. In this article, we will answer some frequently asked questions (FAQs) related to this proposal.

Q: Why do we need to deprecate CubiomesInternal?

A: We need to deprecate CubiomesInternal because it is not intended to be used directly by external consumers of the Cubiomes library. Its primary purpose is to provide a low-level interface to the library's internal implementation details. By using this package, we are essentially bypassing the CubiomesKit package, which is the recommended way to access the Cubiomes library.

Q: What are the benefits of using CubiomesKit instead of CubiomesInternal?

A: The benefits of using CubiomesKit instead of CubiomesInternal include:

  • Tight coupling: By using CubiomesKit, we are not tightly coupling our app to the internal implementation details of the Cubiomes library.
  • Maintenance overhead: Using CubiomesKit requires us to maintain a shallow understanding of the library's API, which is more maintainable than the internal implementation details.
  • Stability issues: The CubiomesKit package is designed to be stable and maintainable, which reduces the risk of breaking changes.

Q: How will we type-alias specific types from CubiomesInternal?

A: We will type-alias specific types from CubiomesInternal to make them available in CubiomesKit. This will involve creating new types in CubiomesKit that are equivalent to the types in CubiomesInternal.

Q: What new structures will we need to add to CubiomesKit?

A: We may need to add new structures to CubiomesKit to allow for the same functionality as CubiomesInternal. This will involve creating new classes, protocols, or enums in CubiomesKit that are equivalent to the structures in CubiomesInternal.

Q: How will we add SwiftLint rules to enforce the usage of CubiomesKit?

A: We will add new SwiftLint rules to enforce the usage of CubiomesKit instead of CubiomesInternal. This will involve creating new rules in SwiftLint that check for the usage of CubiomesInternal and report an error if it is used.

Q: What is the timeline for implementing this proposal?

A: We will implement this proposal in the following steps:

  1. Review the Cubiomes library: We will review the Cubiomes library to identify the specific types and structures that need to be type-aliased or added to CubiomesKit.
  2. Type-alias specific types: We will type-alias specific types from CubiomesInternal to make them available in CubiomesKit.
  3. Add new structures: We will add new structures to CubiomesKit to allow for the same functionality as CubiomesInternal.
  4. Add SwiftLint rules: We will add new SwiftLint rules to enforce the usage of CubiomesKit instead of CubiomesInternal.
  5. Test and verify: We will test and verify that the proposed solution works as expected and does not introduce any breaking changes.

Conclusion

Deprecating the external usage of CubiomesInternal and instead relying on the CubiomesKit package will make our app more maintainable, stable, and easier to use. By following the proposed implementation plan, we can ensure a smooth transition to the new package and avoid any breaking changes.