This is the main repository for events organized by the Ethereum Foundation
- Devcon - the Ethereum conference for developers, thinkers, and makers.
- Devconnect - a week-long gathering of independent Ethereum events to learn, share, and make progress together.
- devcon - main Devcon website @ devcon.org
- devcon-api - API for all Devcon-related apps @ api.devcon.org
- devcon-app - Devcon conference scheduling App @ app.devcon.org
- devcon-archive - Devcon video archive @ archive.devcon.org
- devconnect - main Devconnect website @ devconnect.org
- data - all Devcon data, recorded talks, sessions, speaker info, etc.
- lib - shared components for all projects
- npm install inside lib before you start for types to be available in lib
- run whichever project you like as if you weren't working in a monorepo
- the reason we don't use yarn workspaces to solve shared dependencies is that there were too many hacks required to make it work - hoisting means typescript gets confused, webpack/nextjs gets confused, weird edge cases/traps, harder to reason about, harder to install in isolation on netlify, and so on - it sounds simple in theory, but it isn't (as of 19/10/2023).
- lib actually doesn't need all dependencies installed, just enough for types to be present/for typescript to work (e.g. @react/types is enough, it doesn't also need to install react, even though it uses react, read more below). Note: some packages may need to be installed simply because the types are included in the package itself. But this is fine; no harm done even if you install too much, it won't get used anyway (read more below).
- the actual dependencies must be installed by the project that uses lib ("the consumer") - we then use simple webpack config to tell any imports from lib to resolve dependencies in the consumer's node_modules rather than it's own - no package hoisting needed (and the complications that brings), and we only have one source of dependencies (no version conflicts, no duplicated output, etc.). This also means its the consumers responsibility to have all packages installed when it uses lib - which is fine, but worth keeping in mind, because it also means changes to lib that require new packages or versions need immediate action in the consumers.