# Aqua project structure I propose that we have two different project structures for 2 different use-cases: 1. Aqua libraries 2. Application code ## Aqua libraries These are created by author with intention of the library to be used by other people. For that purpose, they are published to various package distribution resources: - Currently, Aqua code is published to NPM Code emitted during compilation should be published to their corresponding package distribution system: - Emitted TypeScript code is also published to NPM - Emitted Rust code is published to crates.io - Emitted Elm code to elm package registry - And so on ### Open questions 1. Should Aqua code be published separately from emitted TypeScript code? - I'd say NO cuz I think it's better to publish them together as we do now. 2. For TypeScript, should Aqua compiler generate `index.ts` that exports all Aqua functions? It will contain only exports like: `export * from ./pubsub` - I'd say NO cuz while it's handy to have it generated in simple cases, it becomes hard to manage if you need to customize `index.ts` #### Directory structure for libraries I'll use `ipfs-adapter` as an example. ``` . ├── aqua │   ├── README.md -- README that's published to NPM │   ├── ipfs-api.aqua │   ├── ipfs.aqua │   ├── package-lock.json │   ├── package.json -- Describes: 1) Aqua build 2) TS build 3) publishing of Aqua+TS as @fluencelabs/aqua-ipfs │   ├── tsconfig.json -- Configured to emit JS to typescript/dist │   ├── rust │   │   ├── Cargo.toml │   │ ├── src -- Contains generated code + custom code │   │ │   ├── ipfs-api.rs -- Generated from Aqua │   │ │   └── main.rs -- Custom code written by author │   │   └── target -- │   └── typescript -- Contains generated code + custom code │   ├── dist -- │   ├── index.ts -- Custom code written by author │   └── ipfs-api.ts -- Generated from Aqua code ├── service -- Rust service written by author │   ├── src/main.rs │   ├── artifacts/ipfs.wasm │   ├── build.sh -- Build ipfs.wasm and generate aqua/ipfs.aqua │   └── Cargo.toml ├── examples │   ├── typescript -- Example of how to use TypeScript API │   │ ├── index.ts │   │ └── package.json -- Depends on @fluencelabs/aqua-ipfs locally | └── local-network |    └── docker-compose.yml -- Helper to run local Fluence cluster to run examples locally └── README.md -- README that's visible in the repo root ``` The most disturbing thing for me here is that `aqua/package.json` describes 2 things: Aqua and Typescript. But it seems that having `aqua/package.json` and `typescript/package.json` it way too complicated. ## Aqua application code Let's consider `examples/intro/3-hello-world-web3` here. ``` . -- ├── tsconfig.json -- ├── package-lock.json -- ├── package.json -- Describes Aqua build and React build ├── aqua -- │   └── getting-started.aqua -- Application Aqua code ├── public -- Application resources │   ├── favicon.ico -- │   ├── logo192.png -- │   └── index.html -- ├── src -- Application TS/JS code │   ├── _aqua -- TypeScript emitted from Aqua │   │   └── getting-started.ts -- │   ├── App.scss -- │   ├── App.tsx -- │   ├── index.css -- │   └── index.tsx -- ├── build -- Application build directory │   ├── favicon.ico │   ├── index.html │   └── static │   ├── css │   ├── js │   └── media └── README.md -- Repository readme ``` In this example, there is no Rust service, just frontend application. The only change I'd proposed here is to rename `_aqua` to `generated`. ## Aqua application code with service In case where there is a Rust service, I'd propose the following structure. ``` . ├── README.md ├── aqua │   └── getting-started.aqua ├── service │   ├── Cargo.toml │   └── src │   └── main.rs └── web ├── build ├── package.json ├── public ├── src └── tsconfig.json ``` It's the same as the previous one, except everything except `aqua` and `README` is moved under the `web` directory