Should we keep having a single package.json for the Aragon app + the web app?

aragon / aragon-app-dx

This project is meant to discuss and shape the ideal experience we want for Aragon app developers (based on the Aragon React Kit Boilerplate).

8 stars 2 forks source link

Should we keep having a single package.json for the Aragon app + the web app? #1

Open bpierre opened 6 years ago

bpierre commented 6 years ago

Pros:

Simpler to manage: a single package.json means a single version, name, and package-lock.json to maintain.

Cons:

The dependencies of the two apps are mixed together. https://github.com/aragon/aragon-app-dx/blob/master/package.json#L5-L15
By default with parcel, the babel configuration has to be at the level of the package.json, making it identical for both projects.
As the two apps grow, more configuration will likely be added to the package.json or its directory, which might cause conflicts or difficulties to understand which app is using what.

@izqui @sohkai thoughts?

izqui commented 6 years ago

Adding another con, all 'first-party' Aragon apps use separate packages for the contracts and the webapp. I think we should make the default developer experience as similar as possible to what we consider the best way of building Aragon apps is.

sohkai commented 6 years ago

I like logically separating things as much as possible, to avoid confusion. I've even been thinking about making the contracts go into a different subdirectory, so that it might look something like:

app-root
   |
   |--- frontend
           |--- src
           |--- package.json
   |--- evm
           |--- contracts
           |--- package.json

And maybe lerna at the root to make it easier to install all in one go?

luisivan commented 6 years ago

I wouldn't call the subdir EVM though, imagine that in the future Aragon apps run on WASM

bpierre commented 6 years ago

Some ideas of variable correctness: onchain, backend, ethereum-backend, ethereum-app, contracts, smart-contracts, ethereum, arapp, solidity.

I was also thinking about webapp instead of frontend (thinking about projects having several types of frontends in the future), but frontend would work fine for now.

sohkai commented 6 years ago

I guess I like onchain the best out of those, as the name with least confusion. Technically EWASM would still be an "EVM".

izqui commented 6 years ago

And maybe lerna at the root to make it easier to install all in one go?

What about repos that already use lerna to manage multiple apps like aragon/aragon-apps or TPT? Would the idea be that each app uses lerna to manage the two packages or are they all managed by the monorepo top-level lerna? Just worried than adding more packages could make dealing with app monorepos even more painful than it is right now.

sohkai commented 6 years ago

Yeah, don't disagree with that. I was thinking each app would also use lerna to manage the two packages... but that's probably overkill.

bpierre commented 6 years ago

We could also do “lerna without lerna”, only to avoid introducing another tool:

app-root
   |
   |--- package.json <= The name, version and running commands would go here. Some commands
   |                    would only be aliases of local commands in frontend/ and evm/.
   |                    `npm install` would also install the deps in frontend/ and evm/.
   |
   |
   |--- frontend
           |--- src
           |--- package.json <= private: true, local commands and deps
   |--- ethereum
           |--- contracts
           |--- package.json <= private:true, local commands and deps

sohkai commented 5 years ago

With the above, we should also place generic assets, e.g. icons, images, etc. into app-root/assets/, and make sure the publishing tool includes that in its list of files.

The manifest.json should go directly into app-root, and potentially the arapp.json could go into app-root/evm, since it's all contract related.