Set up scaffolding

[jellegerbrandy]

We need different directories for

/player
/portal
/assets (shared assets)

[elia does not agree with this ^^^]

We also need different build and test commands, probably along the lines of:

yarn testPlayer   (run tests in /player)
yarn testPortal (run tests for /portal
yarn test (run all tests)

And, similarly:

 yarn buildPlayer
 yarn buildPortal
 yarn build

@bent0b0x , does it make sense like this?

• still need to separate build processes for embeddable player and portal

[jellegerbrandy]

@eliawk , does this look reasonable to you?

[eliawk]

😄
my proposal for the scaffolding is more components oriented, something like
/components
/modules
/section

i also found this https://arc.js.org/

@bent0b0x @jellegerbrandy @ya7ya @geckoslair what do you think about?

[bent0b0x]

@jellegerbrandy what you laid out makes sense. I'll try and finish up the portal scaffold today and then once I do move it into its own directory (/portal).

As for arc.js, I think we can incorporate most of what it includes on our own, so not sure if it gives us too much benefit at this point.

[bent0b0x]

Also @eliawk I still plan on adding more structure to the js, including separate directories for components and such

[jellegerbrandy]

We still need a separate builds for player and portal.

[bent0b0x]

I think I might want to talk a bit more about player and portal in the same repo. Combining the projects will add a layer of complexity, and I'm not totally clear on what the benefit will be. Is it purely to share assets, i.e. static images/svgs? Given that we are planning to use styled-components in the portal app, we don't really have a clear path to share styles.

If we are really only sharing images, my question would be do we anticipate using enough of these static assets to warrant colocating the projects? I think it would not be too much of a burden to create a separate deployable npm package from which we can import icons and images. If we want to add a new icon to the portal, we would need to PR the assets repo, merge and then release a new version. Then we would submit a PR to the portal app to take this new dependency. So it is a tiny bit cumbersome, but honestly IMO not that bad. I have worked with similar systems in the past with decent success.

Managing two separate projects within one package.json, having two separate webpack configs, and possible entirely separate toolchains could end up cluttering this repository and be confusing to manage, so I want to make sure we are getting enough out of it to go down that path.

@jellegerbrandy @eliawk thoughts?

[jellegerbrandy]

good points. Here are some more observations:

• there is a difference bewteen "npm package" and "github repo". t's ok to develop different packages in one repo (look wat web3 does: https://github.com/ethereum/web3.js/tree/1.0/packages)
• having different builds from the same code: we may also imagine that we have different player-builds (with or without certain functionality, say); that we have builds for different platforms, etc.
• (Not directly relevant to the discussion, but: I think the publsh-to-npm-and-then-import-again is just cumbersome and unnecessary, as we can also install packages directly from github.)
• the bottom line, I think, is that developing both player and portal in the same repo would not only be for sharing static assets, but also to (1) keep development in sync (i.e. not having to keep different repo's in sync) and (2) share devpops infrastructure (test suite, CI, deployment procedure, etc.

At this point, my personal opinion tends to agree with @bent0b0x and to have separate repositorie after all.

[jellegerbrandy]

I'm closing this for now - we can revisit this later if necessary