Journey-hacks-site

Static site development for Journey hacks 2025.

Setup

1. pull the repo with your method of choice
2. run npm install in repo to get dependencies
3. install svelte's vacode extension: Extention
   • This Snippet extention might be useful too.
4. run npm run dev to start the dev server.

Useful resources

• Figma designs
• Vector assets exports (from figma)
  • note that *.svg files downloaded may need to be minimized before use
  • this seems like a good choice to do so
• Svelte docs
  • alternatively, just dm @goldentoaste for help :P
  • we are not anticipating many framework specific code for this static site.

Project structure

Global styles

• All global style/css should go in src/app.css, it will be shared amongst all component/pages
• styles for a particular component can either be done in tailwind, or in <style> </style> tag of the component itself.

Main page

• src/routes/+page.svelte
• This site will only have a single page, which we will implement the sections of it in their own components
• Each section of the page should have an id such that user can jump to a section with <a href="#sectionName"/>.

Components

• src/lib/components
• see src/lib/components/example.svelte for basic examples of a svelte component
• Each .svelte file is a component, which contains all the script, template, and style this component has.
• Components in the lib folder are setup to be imported with import CompName from "$lib/components/CompName.svelte
• Usage of components, ie, passing props to it is similar to React.

Static assets

• static/...
• All static assets, such as fonts, svgs or other images goes in the static folder.
• Assets in static can be referenced by "/foldername/filename", for example if there is a static/icons/plus.svg, then in any .svelte file, you can do:

<img src="/icons/plus.svg" alt="plus icon"/>

Workflow

Since the scope of the site is limited, we won't be using a issue/PR system. Instead, we will have:

• prod branch, publicly deployed
• dev branch, deployed and used for internal preview. (dev will be the default branch)
• developer name branch, each developer codes in their own branch.

When feature in your branch is ready to be deployed to dev/preview, do the following:

1. update from dev
2. resolve any conflicts from the update
3. test locally and check if everything looks as intended still
4. merge your branch into dev.

Deployment

The site will be deployed on Netlify.

• prod branch is the public branch
  • pushing to prod requires at least 1 review in PR, which gets a review deployment
• preview for internal preview
  • pushing to preview cause a deployment, No PR
• dev for merging development progress, no deploys in this branch