Refactor project structure

[kasperski95]

Previously, features specific to a command were kept in the command folder. As the application grow, features started to be shared across multiple commands.

Suggested project structure:

protostar
  - commands
      - build_command.py
      - ...
  - shared                      # keep it small — increases coupling
      - constants.py        # e.g. link to the protostar repository
      - protostar_exception.py
  - features                    # contains only packages not modules
      - cli
      - starknet_gateway
      - starknet_compiler
      - testing
      - ...
   - protostar_cli.py
   - composition_root.py
   - start.py

• commands can import from shared, features and other commands
• features can import from shared other features

[mkaput]

sorry for being that guy, but I don't personally see a need to have distinct shared and features hierarchies. There's no added value over putting shared stuff under protostar and particular features under protostar.testing or protostar.starknet_gateway for example.

but this is a matter of taste :)

[kasperski95]

I don't have a strong opinion on the project structure, but I'd like to define some structure we try to follow.

You're right, Shared/Utils/Core is probably a bad idea.

Features is a pattern from Redux Toolkit but I don't have a strong opinion on that either.

[mkaput]

@MaksymilianDemitraszek @Radinyn opinions?

[MaksymilianDemitraszek]

There are definitely some benefits coming from @kasperski95 proposal but honestly I don't see much issue with the current structure. It's true that test command dir became a bit bloated but generally stuff included there is not shared outside of the command, so hoisting it up to some arbitrary dir abstraction IMO will make it more confusing.

Generally I would prefer to not adapt structure from a frontend framework as it is designed to generalize among many possible apps (to make developers working in many apps using the same framework easier and work well with abstractions provided by the framework). If we are not using a framework we can let dir structure grow at its own pace and address problems reactively the way that fits our domaia.

Summing up, I think we just cannot come up with an arbitrary structure that will address all of our future problems, because we just can’t predict the future.

I hope it makes sense and thank you @kasperski95 for your contribution I think the general idea is very good just maybe not worth adressing ATM.

[kasperski95]

Right, I'll follow this pattern then. I'll not use utils directory.

protostar
  - commands
      - build_command.py
      - ...
   - feature1
   - feature2
   - feature3
   - ...
   - protostar_cli.py
   - composition_root.py
   - start.py

[kasperski95]

Generally I would prefer to not adapt structure from a frontend framework

@MaksymilianDemitraszek You already do https://react-file-structure.surge.sh/

[kasperski95]

It seems we use Screaming Architecture. Closing.