Consider not importing default payload implementations for production applications #14

New issue

Closed

opened 2025-12-28 17:07:40 +00:00 by sami · 0 comments

sami commented

2025-12-28 17:07:40 +00:00

Owner

Originally created by @roman-khimov on GitHub (Feb 9, 2024).

I'm always frustrated when we import/build code we don't need. We have payloads/block implementations that are imported by default, but no real application uses them. They're useful for tests, they can be provided for edge cases, but they're not needed to be present in production builds.

Describe the solution you'd like

Drop defaults for New* payload callbacks. They still can be used via payload.* methods, we can even add some method to provide the default set of options for all of them, but we can avoid importing them in NeoGo or Bane.

Describe alternatives you've considered

Keep this code in our builds. Nothing critical with this, btw.

Additional context

https://github.com/nspcc-dev/dbft/pull/89
https://github.com/nspcc-dev/dbft/issues/90

Originally created by @roman-khimov on GitHub (Feb 9, 2024). ## Is your feature request related to a problem? Please describe. I'm always frustrated when we import/build code we don't need. We have payloads/block implementations that are imported by default, but no real application uses them. They're useful for tests, they can be provided for edge cases, but they're not needed to be present in production builds. ## Describe the solution you'd like Drop defaults for `New*` payload callbacks. They still can be used via `payload.*` methods, we can even add some method to provide the default set of options for all of them, but we can avoid importing them in NeoGo or Bane. ## Describe alternatives you've considered Keep this code in our builds. Nothing critical with this, btw. ## Additional context https://github.com/nspcc-dev/dbft/pull/89 https://github.com/nspcc-dev/dbft/issues/90