This article will take you through the AI Commerce frontend folder structure, development environment, and how to leverage a common codebase across multiple stores. The goal of this article is to give integration partners a clear understanding of how the frontend is organized and what files and dev dependencies are used in the project.

By following the guidelines below, you can more effectively manage the development of AI Commerce 's user interface, understand the principles of version control, and ensure that your code remains secure and easily maintainable.

Frontend file structure and key directories

• /assets/ – Files that go in the root of the project, such as robots.txt and favicon.ico. When going into production, noindex must be removed from the robots.txt file.
• /dist/ – JS and CSS files generated by Vite and AI Commerce 's SSR plugin that end up in S3 and Lambda.
• /node_modules/ – Third-party libraries, listed in the package.json file. New libraries are only added by the Code Owner.
• /src/ – Actual application code:
  • /src/app – Core frontend functionality, e.g. router, cookies, and other less frequently updated code.
  • /src/ext – Third-party scripts, including codes for chats and embeds like Builderio, that have been converted to fit AI Commerce environment.
  • /src/lib/ – Functionalities that can be customized per store. For example , Configuration.js , which defines things like logoRatio .
  • /src/modals/ – Various reusable modal components.
  • /src/pages/ – Application page files (routing), used to create dynamic paths like /product/[slug] .
  • /src/popups/ – Various popup components.
  • /src/renderer/ – Server-side rendering (SSR) related files such as App.svelte , +onBeforeRender.js , +onRenderHtml.js , and +onRenderClient.js .
  • /src/ssr/ – AI Commerce 's own SSR files, intended as a lightweight server-side rendering solution.
  • /src/styles/ – Style files (global.css, dynamic.css, common.css). It is recommended to keep most styles component-specific, but for example, it is worth styling general HTML or dynamic content in these files.

Dev dependencies and their purpose

The project uses only essential libraries, which are locked in the package.json file. This ensures the security and efficiency of the code. Only Code Owners can update or add new libraries. The following packages can be found in the devDependencies section of package.json:

• @sveltejs/vite-plugin-svelte (3.1.1) – Enables the use of Svelte components in a Vite project.
• cross-env (7.0.3) – Platform-independent environment variable setting.
• dotenv (16.4.5) – Loads variables from an .env file into process.env during build or runtime.
• eslint (^9.14.0) – Lint tool for JavaScript/TypeScript code.
• eslint-plugin-svelte (2.46.0) – ESLint support for Svelte files.
• sass (^1.86.3) – A compiler for translating SCSS/Sass files into CSS.
• serverless-prune-plugin (2.1.0) – Serverless plugin for removing old deployment versions in AWS.
• svelte (4.2.19) – Svelte library in development, compiled during build.
• svelte-preprocess (^6.0.3) – Enables the use of, for example, SCSS and TypeScript in .svelte files.
• vite-plugin-compression (0.5.1) – Adds gzip or brotli compression to built files.
• vite-plugin-dynamic-import (1.5.0) – Dynamic imports in Vite projects (e.g. lazy load routes).

.env.local

Environment variables are stored in the .env.local file. This is where you define, for example, connection points for backends and image servers. Variables marked with the VITE_ prefix are also visible in the browser, so do not store sensitive data in them.

• VITE_BACKEND_HOST – Backend host name (e.g. localhost or boeing.com ).
• VITE_DEV_IMAGE_URL – The address of the CDN or image server from which images are loaded in the development environment.
• VITE_LANGUAGE_CODE – Language code of the default language (e.g. fi). Used to select route maps.

Linters and other configurations

eslint.config.js defines linting rules to keep the code consistent and detect potential errors or unused variables in a timely manner. Other configuration is managed in the files serverless.yml and vite.config.*.js , which are maintained by AI Commerce core team and locked behind Code Owners.

Language version management

languageMap.js , routeMap.js , routeMapGenerator.js , routeTranslations.js and routeTranslator.js are responsible for language-specific route maps. Adding new languages is done by AI Commerce , so the finished maps and route definitions are distributed to all stores automatically.

S3Fallback and routing failover solutions

s3Fallback.js handles cases where no direct answer is found for the requested route. First, we check whether a route for the path is found on the front-end. If not, we try again at the S3 level. If the route is not found there either, an HTTP 404 code is returned. This ensures, among other things, that Google has the right status code when indexing pages.

Summary

AI Commerce frontend follows a clear folder structure that makes it easy to maintain and reuse across stores. All general improvements and bug fixes are primarily made to the main branch, from where they are automatically pushed to the different stores. Dev dependencies have been kept to a minimum to keep the project lightweight, secure, and easy to update. Hopefully, this guide will help you understand how to work efficiently with AI Commerce frontend.