You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Split the scaffold package (pkg/scaffold) in two separate packages.
Motivation
The scaffold package has most of the code of this project and is getting pretty hard to deal with. Splitting it into two separate packages could make development and maintaining easier. It currently contains both the scaffolding machinery and the files that will be generated (there are currently 73 implementations of the File interface, plus additional files for tests and utils).
The proposed packages would split the scaffolding machinery from the files themselves. The name of the new package could be one of the following, depending on the external exposure needs:
IMHO, the files implementations doesn't need to be exported, so one of the internal options could be used. This way, the exported surface of kubebuilder would be reduced, making easier to make changes without breaking third-party tools that relied on these files. Reduced exported surface equals reduce exposed surface from a security perspective too.
From options 2-4, I think that the best fit is option 3. From a design perspective, exposing files to the command package doesn't seem a good choice, so I think that the 3rd and 4th options fit better than the 2nd. Option 3 does a better job in splitting scaffolding machinery and files, while the 4th still keeps a big scaffold package.
/kind feature
The text was updated successfully, but these errors were encountered:
Feature
Split the scaffold package (
pkg/scaffold
) in two separate packages.Motivation
The scaffold package has most of the code of this project and is getting pretty hard to deal with. Splitting it into two separate packages could make development and maintaining easier. It currently contains both the scaffolding machinery and the files that will be generated (there are currently 73 implementations of the
File
interface, plus additional files for tests and utils).The proposed packages would split the scaffolding machinery from the files themselves. The name of the new package could be one of the following, depending on the external exposure needs:
1-
pkg/files
2-
internal/files
3-
pkg/internal/files
4-
pkg/scaffold/internal/files
IMHO, the files implementations doesn't need to be exported, so one of the internal options could be used. This way, the exported surface of kubebuilder would be reduced, making easier to make changes without breaking third-party tools that relied on these files. Reduced exported surface equals reduce exposed surface from a security perspective too.
From options 2-4, I think that the best fit is option 3. From a design perspective, exposing files to the command package doesn't seem a good choice, so I think that the 3rd and 4th options fit better than the 2nd. Option 3 does a better job in splitting scaffolding machinery and files, while the 4th still keeps a big scaffold package.
/kind feature
The text was updated successfully, but these errors were encountered: