On Friday, 3 November 2023 at 00:19:48 UTC, Andrey Zherikov wrote:
Is there any guide how one can refactor single-module package
into multi-module package with distinction between public and
private modules?
Call the modules literally anything else and it works better.
So say you have module foo.bar. You could keep that and put your
multiple modules in a different thing like foo.bar_parts.part and
foo.bar_parts.part2. This maintains compatibility on the user
side; if they were previously using foo.bar, things keep working
for them.
Or, you could keep everything under foo.bar, but add a
foo.bar.all that provides the old api. Users would have to adjust
their imports to say `import foo.bar.all;` instead. This has more
potential for transition breakage, but it keeps the new modules
under the old namespace.
I recommend option 1: having the new foo.bar_parts where the
implementation actually goes. (Or you could call it whatever you
want.) This avoids the whole package.d thing while still letting
you and your user arrange modules how you like.
You might also have a thing like `foo.bar_implementation` which
is not intended for public use.
