Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"Over-exposed" utility functions #385

Closed
AuHau opened this issue Aug 3, 2021 · 2 comments · Fixed by #395
Closed

"Over-exposed" utility functions #385

AuHau opened this issue Aug 3, 2021 · 2 comments · Fixed by #395

Comments

@AuHau
Copy link
Contributor

AuHau commented Aug 3, 2021

Looking on what is exposed as part of the Utils namespace, I think there is a lot of parts that are purely internal and I am not sure why user should have access to it. Especially as it extends the public API that is then tightened to SemVer.

export * as Collections from './collection' // <- should expose only the helpers the @Cafe137 created
export * as Bytes from './bytes' // <- also not sure if it is needed
export * as Data from './data' // <- I would definitely remove this one
export * as File from './file' // <- This will be removed in the directory streaming PR
export * as Hex from './hex' // <- I guess this one makes sense
export * as Tar from './tar' // <- I would definitely remove this one
export * as Eth from './eth' // <- This one makes sense
export * as Hooks from './hooks' // <- This one could be only deprecated with the Fetch PR, but if we gonna have breaking release we might remove it as well.
export * as Pss from './pss'
export { setDefaultHeaders } from './safe-axios'
export { keccak256Hash } from './hash'
@bee-runner bee-runner bot added the type:issue label Aug 3, 2021
@agazso
Copy link
Member

agazso commented Aug 3, 2021

Maybe I would go as far as not having export * because it can have unintended consequences. For example an internal utility function exposed publicly, then after an internal refactor landing in a different file would break the public API.

@r0qs is there anything in the above list that would negatively affect you?

@r0qs
Copy link

r0qs commented Aug 9, 2021

Hi, thanks for considering my use case. I indeed use those functions, mostly the eth, hex and bytes modules.
But after our discussion around the issue #379 I decided to do my own wrapper around the bee api to have more control over the feeds and pss functionalities.
So this change will not affect me anymore:)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants