Skip to content

04 — Your first contribution to someli-platform

A walkthrough for your first FE ticket end-to-end.

1. Pick a small first task

Ideal first tickets:

  1. Doc fix in ../../audit/someli-platform/ — a typo, an outdated CDN URL, a [VERIFY] marker.
  2. A text/copy change. Tweak a button label, a placeholder, an error message. You'll touch components/<Group>/<Name>.vue and learn how component auto-registration works.
  3. A console.log cleanup — ../../code-inspect/someli-platform.md lists specific PII-leaking logs to remove.
  4. A small new field on an existing page. Add a "last login" display to the user profile. Touches one page, one store action.

Avoid for your first PR: anything inside polotno-editor/, anything touching middleware/redirect.js (subtle auth implications), anything that changes the axios interceptor.

2. The edit-run-verify loop

cd ~/src/someli/someli-platform

# 1. Branch
git checkout dev_app
git pull origin dev_app
git checkout -b feature/first-pr

# 2. Edit
# - open the page in pages/ or the component in components/
# - or the store action in store/

# 3. Run
yarn dev                      # http://localhost:3000 — HMR auto-refreshes

# 4. Verify
# - open the page in the browser
# - exercise the feature you changed
# - check Vue DevTools for Vuex state changes

HMR is usually instant for component changes. Some changes need a manual refresh: - changes to nuxt.config.js - changes to store/index.js root - changes to middleware

For those, stop and restart yarn dev.

3. Entry points to know — a 30-minute reading tour

Open these in this order, just to scroll through and absorb the shape:

  1. nuxt.config.js (the whole file). The single most important file in the repo.
  2. middleware/axios.js — short. Read every line. This is how requests get authenticated.
  3. middleware/redirect.js — read. This drives post-login routing.
  4. middleware/appendUrl.js — short. Explains the account-prefix URL rewriting.
  5. store/api.js — the cache layer. Read it.
  6. store/index.js root — short.
  7. One feature's Vuex module of your choosing — e.g. store/post/. Open state.js, getters.js, mutations.js, actions.js.
  8. One page of your choosing — e.g. pages/_accid/contentplanner.vue or pages/_accid/dashboard/index.vue. Notice how data(), mounted(), and Vuex dispatches fit together.
  9. helpers/helper.js — the post-status state machine lives here (renderPostStatus, calStatus). Many features depend on it.

After this tour, you know where almost anything in the customer FE lives.

4. Reading-around your task

  1. Grep. From the project root, search for a unique string near where you'll make changes: 
    grep -rn 'My Feature Label' components/ pages/ store/ helpers/
  2. Open the audit doc for the topic. Examples:
  3. Post lifecycle → ../../audit/someli-platform/13-post-lifecycle.md
  4. State management → ../../audit/someli-platform/05-state-management.md
  5. Polotno → ../../audit/someli-platform/06-polotno-integration.md
  6. Onboarding flow → ../../audit/someli-platform/15-onboarding-flow.md
  7. Layouts → ../../audit/someli-platform/16-layouts.md
  8. Permissions / roles → ../../audit/someli-platform/12-permissions-and-roles.md
  9. Check code-inspect. If your file is in ../../code-inspect/someli-platform.md, there might be a known bug nearby — don't trip over it.

5. Manual testing

There is no test suite. Always exercise:

  1. The happy path in the browser.
  2. Logged-out behaviour — does the page redirect to /login?
  3. Wrong account — switch accounts, does the page handle it?
  4. Slow network — Chrome DevTools → Network → "Slow 3G". Loading skeletons / spinners should still work.
  5. Cookie cleared — Application tab → Clear storage → reload. Does the app handle it cleanly?

Always test against multiple browsers for visible UI changes (Chrome, Firefox, Safari if you have access). Bootstrap-Vue can render differently between browsers.

6. Useful local helpers

Devtools

  • Vue DevTools v6.x (legacy version, REQUIRED for Vue 2) — component tree, Vuex panel, event timeline.
  • Vuex panel — inspect store state live as you click around.
  • Network panel — watch axios requests; verify the token / accountId / apptype headers are present on requests under /auth/.

Hot path: cookies

Most auth surprises trace to cookies. In DevTools → Application → Cookies for localhost:3000 you should see: - auth.strategy (@nuxtjs/auth's record of which strategy) - auth._token.local (the actual token) - usedetail (account info — drives accountId)

If one is missing, the app's behaviour is undefined.

7. Opening the PR

yarn format                   # Prettier — repo enforces this
git add -p                    # review what you're committing
git commit -m "Add 'last login' to profile page"
git push -u origin feature/first-pr
# Open PR on github.com/Someli-ai/someli-platform → dev_app

PR description should include:

  • A short why
  • A short what
  • Screenshots (before/after) for any UI change
  • Manual test plan
  • Any new env var or new CDN script (call out at top)

8. After merge

  1. Watch the Jenkins dev_app deploy (UI in the team's Jenkins).
  2. Hit the dev URL in the browser and re-verify.
  3. Pull and clean up: 
    git checkout dev_app && git pull
git branch -d feature/first-pr

9. Common first-PR mistakes

Mistake Why it bites Avoid by
Committing polotno-bundle.js regenerated from a local Polotno change without intending to Random Polotno edits ride along Only rebuild polotno-bundle.js if your PR is specifically about the editor
Calling this.$axios.get('/auth/...') directly instead of via store/api Bypasses cache; causes redundant API calls Use store.dispatch('api/fetch*')
Adding a new CDN script No SRI, no version pin — a CDN compromise = XSS Prefer adding to package.json if possible
Mutating Vuex state directly Store is non-strict so this works — but breaks devtools time-travel and is hard to trace Always use mutations / actions
Forgetting the <no-ssr> guard for client-only third-party widgets Crash on build (yes, even though ssr is off — the build still walks templates) Wrap in <no-ssr> or import in mounted()
Editing the Polotno editor in polotno-editor/ and forgetting to yarn build The Nuxt app still loads the old bundle After editing, cd polotno-editor && yarn build
Putting the same fix in someli-platform/polotno-editor/ and not in Someli-Designer/polotno-editor/ The designer's editor still has the bug Check whether the change applies to both forks

Next

→ 05-where-to-look.md — the troubleshooting routing table.