Monorepo

[0xjei]

This monorepo approach where the CLI commands have a dedicated package of actions and helpers, the backend is organized in a more generic fashion will ease the burden of testing and maintainability.

BREAKING CHANGE: The folder structure and build process (now using lerna)

re #175

[baumstern]

In general, it looks like package structure is neat and easy to understand, also easy to extend. Great work!

[ctrlc03]

In general, it looks like package structure is neat and easy to understand, also easy to extend. Great work!

+1 great stuff Jei

[0xjei]

Not directly relevant this PR but think COPYRIGHT HOLDER part of LICENSE file should be organisation.

Yes, I think we should talk about licensing internally w/ the team. BTW, I will start switching from "myself" to EF or PSE (MACI/QFI) team whenever needed.

[0xjei]

How about to move packages/actions directory to packages/phase2cli/src/actions? Exported functions of packages/actions are highly context dependent of phase2cli. (The directory structure like packages/actions/src/core/auth gives impression that it will provide complete functionality of authentication, since it has general naming)

My original idea was to disassemble the core of the CLI as much as possible from what pertains to the UI (e.g., console.log, theme). That way, it would be possible for anyone to write their own interface of the CLI and extend/improve the core easily.

Now, as you correctly stated, the actions package has a strong dependency on the CLI. So, def. your proposal makes more than sense because we could still work on simplify the testing process and write modular code. Also, the dependency between the two packages would be removed.

I think what I was initially trying to do (complete modularization) is more suitable in the future when the suite will become a more mature toolset.

What are your thoughts? And thanks for the great insight!

[ctrlc03]

How about to move packages/actions directory to packages/phase2cli/src/actions? Exported functions of packages/actions are highly context dependent of phase2cli. (The directory structure like packages/actions/src/core/auth gives impression that it will provide complete functionality of authentication, since it has general naming)

My original idea was to disassemble the core of the CLI as much as possible from what pertains to the UI (e.g., console.log, theme). That way, it would be possible for anyone to write their own interface of the CLI and extend/improve the core easily.

Now, as you correctly stated, the actions package has a strong dependency on the CLI. So, def. your proposal makes more than sense because we could still work on simplify the testing process and write modular code. Also, the dependency between the two packages would be removed.

I think what I was initially trying to do (complete modularization) is more suitable in the future when the suite will become a more mature toolset.

What are your thoughts? And thanks for the great insight!

Personally I agree with Jei on this. Separating everything now will make it easier for anyone to build their own cli/ui by using the actions package.

[0xjei]

How about to move packages/actions directory to packages/phase2cli/src/actions? Exported functions of packages/actions are highly context dependent of phase2cli. (The directory structure like packages/actions/src/core/auth gives impression that it will provide complete functionality of authentication, since it has general naming)

My original idea was to disassemble the core of the CLI as much as possible from what pertains to the UI (e.g., console.log, theme). That way, it would be possible for anyone to write their own interface of the CLI and extend/improve the core easily.

Now, as you correctly stated, the actions package has a strong dependency on the CLI. So, def. your proposal makes more than sense because we could still work on simplify the testing process and write modular code. Also, the dependency between the two packages would be removed.

I think what I was initially trying to do (complete modularization) is more suitable in the future when the suite will become a more mature toolset.

What are your thoughts? And thanks for the great insight!

Whenever you have some time. FYI ^^^ @daodesigner

[daodesigner]

Few nits but looks good overall! Great job 😊

[baumstern]

How about to move packages/actions directory to packages/phase2cli/src/actions? Exported functions of packages/actions are highly context dependent of phase2cli. (The directory structure like packages/actions/src/core/auth gives impression that it will provide complete functionality of authentication, since it has general naming)

My original idea was to disassemble the core of the CLI as much as possible from what pertains to the UI (e.g., console.log, theme). That way, it would be possible for anyone to write their own interface of the CLI and extend/improve the core easily.
Now, as you correctly stated, the actions package has a strong dependency on the CLI. So, def. your proposal makes more than sense because we could still work on simplify the testing process and write modular code. Also, the dependency between the two packages would be removed.
I think what I was initially trying to do (complete modularization) is more suitable in the future when the suite will become a more mature toolset.
What are your thoughts? And thanks for the great insight!

Personally I agree with Jei on this. Separating everything now will make it easier for anyone to build their own cli/ui by using the actions package.

It makes sense you two. I agree on a package separation would help to enforce decoupling code dependencies and reminds to write modular code :)

[0xjei]

How about to move packages/actions directory to packages/phase2cli/src/actions? Exported functions of packages/actions are highly context dependent of phase2cli. (The directory structure like packages/actions/src/core/auth gives impression that it will provide complete functionality of authentication, since it has general naming)

My original idea was to disassemble the core of the CLI as much as possible from what pertains to the UI (e.g., console.log, theme). That way, it would be possible for anyone to write their own interface of the CLI and extend/improve the core easily.
Now, as you correctly stated, the actions package has a strong dependency on the CLI. So, def. your proposal makes more than sense because we could still work on simplify the testing process and write modular code. Also, the dependency between the two packages would be removed.
I think what I was initially trying to do (complete modularization) is more suitable in the future when the suite will become a more mature toolset.
What are your thoughts? And thanks for the great insight!

Whenever you have some time. FYI ^^^ @daodesigner

We can call on this too. The package structure will have three packages right now:

• phase2cli: CLI interface
• backend: Firebase Cloud Functions + config/scripts for managing the instance (+ S3 config)
• actions: core actions for CL-based interfaces

[daodesigner]

Lgtm!

Agreed on meeting call, let's merge!