Skip to content

Conversation

@hamo-o
Copy link
Contributor

@hamo-o hamo-o commented May 20, 2025

#️⃣ 연관된 이슈>

📝 작업 내용> 이번 PR에서 작업한 내용을 간략히 설명해주세요(이미지 첨부 가능)

  • 루트에 빌드 결과물이 생기지 않아 서버에서 인식하지 못해 에러가 발생했습니다. 이를 해결하기 위해 빌드 경로를 수정했습니다.
  • 현재 서버에서는 루트에서 빌드 결과물을 실행하기 때문에 런타임인 express 역시 해당 경로에 있어야 정상 실행되어, 경로를 바꾸었습니다. (package.json을 복사하고, 이후 설치하는 방법도 있다고 하는데 일반적이진 않은 것 같아요.)

🙏 여기는 꼭 봐주세요! > 리뷰어가 특별히 봐주었으면 하는 부분이 있다면 작성해주세요

각 폴더에 빌드 결과물을 생성하고, 이후 CD과정에서 처리해도 될 것 같긴 한데 고민이네요.
레퍼런스 찾기가 쉽지않네요.. ㅜㅜ 같이 고민해봐요!

Summary by CodeRabbit

  • New Features

    • Introduced incremental TypeScript compilation for faster build times.
    • Added a dedicated TypeScript configuration and bundler setup for the server application.
  • Improvements

    • Updated build output directories for clearer separation of client and server assets.
    • Enhanced deployment workflow with reorganized folder structure and automated dependency installation.
    • Improved type safety, path resolution, and error handling in server setup and middleware.
    • Upgraded Express dependency to a newer version.
    • Streamlined development scripts for both client and server apps.
  • Chores

    • Updated and cleaned up project references and scripts for consistency.
    • Removed unused or outdated script entries and metadata fields.

@hamo-o hamo-o requested a review from dioo1461 as a code owner May 20, 2025 10:18
@coderabbitai
Copy link

coderabbitai bot commented May 20, 2025

Walkthrough

The changes update build scripts, TypeScript configurations, and deployment workflow for both client and server frontend apps. Scripts are refactored for direct use of built server output. TypeScript incremental builds are enabled, and type safety is improved in server code. The deployment pipeline is adjusted to organize build artifacts under a unified dist directory structure.

Changes

File(s) Change Summary
frontend/apps/client/package.json, frontend/package.json, frontend/apps/server/package.json Refactored scripts to run server from built output, removed or added build/preview scripts, updated dependencies, and reordered scripts.
frontend/apps/client/tsconfig.app.json, frontend/apps/client/tsconfig.node.json, frontend/apps/server/tsconfig.json Enabled TypeScript incremental builds and added new server tsconfig for stricter compilation and output to dist.
frontend/tsconfig.json Updated project references to renamed calendar and date-time package paths.
frontend/apps/client/vite.config.ts Set explicit output directory for Vite build and cleaned up plugin formatting.
frontend/apps/server/src/cookies.ts Added explicit TypeScript types to the cookies function and its accumulator.
frontend/apps/server/src/index.ts Improved type safety, path resolution, middleware routing, and error handling in server setup.
frontend/apps/server/tsup.config.ts Added new tsup build configuration for server app with specific build options.
.github/workflows/fe-cd.yml Added step to prepare dist/client and dist/server directories for deployment and adjusted Node.js version quoting; installed pnpm on server before deployment.

Sequence Diagram(s)

sequenceDiagram
    participant Dev as Developer
    participant CI as CI/CD Workflow
    participant Build as Build System
    participant Server as Server App
    participant Client as Client App
    participant EC2 as EC2 Instance

    Dev->>CI: Push code / PR merged
    CI->>Build: Run build scripts (pnpm -r build)
    Build->>Client: Build client output to dist/
    Build->>Server: Build server output to dist/
    CI->>CI: Prepare dist/client and dist/server folders
    CI->>EC2: Copy dist/ folder structure to EC2
    EC2->>Server: Start server from dist/server/index.js
    Server->>Client: Serve built client files from dist/client
Loading

Possibly related PRs

Poem

🐇
A hop, a skip, the scripts align,
TypeScript builds are now divine.
Paths resolved and folders neat,
Dist is ready—what a feat!
With every build, we leap ahead,
The rabbit’s code is finely spread.
🥕


📜 Recent review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between adf0c50 and 8166292.

📒 Files selected for processing (1)
  • frontend/apps/server/tsup.config.ts (1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
  • frontend/apps/server/tsup.config.ts
✨ Finishing Touches
  • 📝 Generate Docstrings

🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Explain this complex logic.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai explain this code block.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read src/utils.ts and explain its main purpose.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

Support

Need help? Create a ticket on our support page for assistance with any issues or questions.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai generate docstrings to generate docstrings for this PR.
  • @coderabbitai generate sequence diagram to generate a sequence diagram of the changes in this PR.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • Please see the configuration documentation for more information.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

@hamo-o hamo-o changed the title [ㄹBugfix/fe/build output [FE-Fix] Express 의존성 위치 변경 및 경로 에러 수정 May 20, 2025
@hamo-o hamo-o added the 🖥️ FE Frontend label May 20, 2025
Copy link
Contributor

@dioo1461 dioo1461 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

각 폴더에 빌드 결과물을 생성하고, 이후 CD과정에서 처리해도 될 것 같긴 한데 고민이네요.
레퍼런스 찾기가 쉽지않네요.. ㅜㅜ 같이 고민해봐요!

제가 이해하기로 현재 문제되는 부분이

  1. cd 시에 루트에 있는 dist를 참조하게 됨
  2. ec2 인스턴스가 /dist/server를 실행할 때, 루트 기준으로 node가 실행되므로 express를 찾지 못함 (express는 /apps/server에 설치돼 있기 때문)
  3. 이를 해결하기 위해 /apps/server에 정의되어있던 express 의존성을 루트로 이전

인 것 같은데요,

제가 이해한 바가 맞다면, 현영님이 말씀하신 "각 폴더에 빌드 결과물을 생성하고, 이후 CD과정에서 처리" 하는 방식이 제 생각엔 더 나아 보이긴 합니다..!

"version": "0.0.0",
"type": "module",
"scripts": {
"build:server": "pnpm vite build apps/server",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

혹시 서버 빌드 스크립트를 server가 아닌 frontend의 package.json에 정의하신 이유가 있으신가요? pnpm -r build를 실행하면 모든 워크스페이스의 build 스크립트가 실행되는데, 현재 frontend에 정의된 build:server 를 server에다가 build 로 정의해도 되지 않을까 싶어서요!

+ 아 혹시 아래 말씀하신 내용 때문에 서버 빌드 스크립트를 루트에 정의하신 걸까요?

현재 서버에서는 루트에서 빌드 결과물을 실행하기 때문에 런타임인 express 역시 해당 경로에 있어야 정상 실행되어, 경로를 바꾸었습니다. (package.json을 복사하고, 이후 설치하는 방법도 있다고 하는데 일반적이진 않은 것 같아요.)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

요건 vite 때문이었습니다..! 각 폴더에 빌드 결과물 생성 후 실행시키려면 스크립트를 꽤 바꿔야 할 것 같아 고민해보겠습니다 의견 감사합니다!

@hamo-o hamo-o requested a review from dioo1461 May 27, 2025 10:55
@hamo-o
Copy link
Contributor Author

hamo-o commented May 27, 2025

다음 프로세스로 변경했습니다.

  1. 각 폴더의 dist에 빌드 결과물 생성
  2. CD 시 루트에 새로운 dist 폴더 생성 후 각 폴더의 dist 결과물 복붙 & 서버의 package.json 복붙 & 패키지 설치
  3. 루트의 dist를 서버로 복붙

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 2

🧹 Nitpick comments (6)
frontend/apps/client/tsconfig.node.json (1)

4-4: Consider excluding tsbuildinfo files from version control
The tsBuildInfoFile under node_modules/.tmp may clutter your repo—ensure you’ve added this path to .gitignore or a dedicated ignore file.

frontend/apps/server/tsconfig.json (2)

11-11: Enable incremental compilation
Incremental builds will generate a default .tsbuildinfo in the project root—consider specifying a custom tsBuildInfoFile (e.g., "./node_modules/.tmp/tsconfig.server.tsbuildinfo") for consistency with other configs.


2-15: Add rootDir to ensure correct source mapping
Explicitly setting "rootDir": "src" prevents stray files outside src from being compiled.

 {
   "compilerOptions": {
     "target": "ESNext",
     "module": "ESNext",
     "moduleResolution": "node",
     "esModuleInterop": true,
     "forceConsistentCasingInFileNames": true,
     "strict": true,
     "skipLibCheck": true,
     "outDir": "dist",
     "incremental": true,
+    "rootDir": "src"
   },
   "include": ["src"],
   "exclude": ["node_modules", "dist", "**/*.test.ts"]
 }
frontend/apps/client/tsconfig.app.json (1)

17-17: Enable incremental builds for app compilation
Incremental compilation will leverage previous build info. Remember to ignore the .tsbuildinfo file in version control.

frontend/apps/server/src/cookies.ts (1)

2-6: Consider defensive programming for malformed cookie strings.

The current implementation assumes well-formed cookie strings. Consider handling edge cases where cookies might be malformed (missing '=' separator or empty cookie strings).

  const cookieStore = cookieHeader.split('; ').reduce((acc, cookie) => {
-    const [key, value] = cookie.split('=');
-    acc[key] = decodeURIComponent(value);
+    const [key, value] = cookie.split('=');
+    if (key && value !== undefined) {
+      acc[key] = decodeURIComponent(value || '');
+    }
    return acc;
  }, {} as Record<string, string>);
.github/workflows/fe-cd.yml (1)

23-23: Minor style inconsistency with quotes.

The change from single quotes to double quotes for the node-version is cosmetic but creates inconsistency with other string values in the workflow file.

Consider keeping consistent quote usage throughout the file. If changing to double quotes, update other string values for consistency.

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 0fb0532 and adf0c50.

⛔ Files ignored due to path filters (1)
  • frontend/pnpm-lock.yaml is excluded by !**/pnpm-lock.yaml
📒 Files selected for processing (12)
  • .github/workflows/fe-cd.yml (3 hunks)
  • frontend/apps/client/package.json (1 hunks)
  • frontend/apps/client/tsconfig.app.json (1 hunks)
  • frontend/apps/client/tsconfig.node.json (1 hunks)
  • frontend/apps/client/vite.config.ts (1 hunks)
  • frontend/apps/server/package.json (1 hunks)
  • frontend/apps/server/src/cookies.ts (1 hunks)
  • frontend/apps/server/src/index.ts (2 hunks)
  • frontend/apps/server/tsconfig.json (1 hunks)
  • frontend/apps/server/tsup.config.ts (1 hunks)
  • frontend/package.json (1 hunks)
  • frontend/tsconfig.json (1 hunks)
🔇 Additional comments (22)
frontend/apps/client/tsconfig.node.json (1)

3-3: Enable incremental builds for Node environment
Enabling incremental speeds up subsequent compilations by reusing previous build information.

frontend/tsconfig.json (2)

8-9: Update project reference paths
Renamed "packages/endolphinCalendar" to "packages/calendar" and "packages/endolphinDateTime" to "packages/date-time". This aligns with the new folder structure.


8-9:

Details

✅ Verification successful

Verify removal of old references
Ensure no lingering import or build references to the old paths remain elsewhere in the monorepo.


🏁 Script executed:

#!/bin/bash
# Search for outdated package paths
rg -l "endolphinCalendar" -l "endolphinDateTime"

Length of output: 104


🏁 Script executed:

#!/bin/bash
# Search for lingering old package identifiers throughout the repo
rg -l -e 'endolphinCalendar' .
rg -l -e 'endolphinDateTime' .

Length of output: 61


No lingering old package references found
Verified by searching the entire repo for endolphinCalendar and endolphinDateTime—no occurrences remain.

All clear to proceed.

frontend/apps/client/tsconfig.app.json (1)

10-10: Approve new path alias for components
Adding @components/* aligns with existing aliases and improves import consistency.

frontend/apps/client/vite.config.ts (2)

16-16: Explicit outDir configuration is clear but redundant.

While explicitly setting outDir: 'dist' improves configuration clarity and aligns with the PR's build output organization goals, note that 'dist' is already Vite's default output directory. The explicit configuration is helpful for documentation purposes.


19-24: Good formatting cleanup.

The removal of trailing spaces in the TanStackRouterVite plugin configuration improves code consistency.

frontend/apps/server/package.json (3)

8-9: Well-structured build and start scripts.

The new scripts using tsup for building and the watch-based start script align perfectly with the PR's objective of improving build output handling. The --onSuccess callback ensures the server runs only after successful compilation.


12-12:

Details

✅ Verification successful

Verify Express v5 compatibility and breaking changes.

The upgrade from Express v4.21.2 to v5.1.0 is a major version jump that may introduce breaking changes. Ensure the server code is compatible with Express v5 changes.


🏁 Script executed:

#!/bin/bash
# Description: Check for Express v5 usage patterns and potential compatibility issues

# Check how Express is used in the server code
rg -A 5 -B 2 "express\(" frontend/apps/server/src/
rg -A 5 -B 2 "from ['\"]express['\"]" frontend/apps/server/src/
rg -A 5 -B 2 "require\(['\"]express['\"]" frontend/apps/server/src/

Length of output: 1176


Express v5 Compatibility Verified

  • Only import of Express is in frontend/apps/server/src/index.ts:
    import express from 'express'
    const app = express()
  • No deprecated v4 patterns detected (e.g. res.send(status, body), standalone body-parser, custom express.Router overloads).

The upgrade to Express 5.1.0 appears safe. Please run your full test suite and smoke-test all endpoints to confirm.


14-17:

Details

✅ Verification successful

Verify @types/express version alignment with Express v5.

The @types/express version ^5.0.2 should be compatible with Express ^5.1.0, but it's worth verifying that the type definitions are up-to-date and accurate for the Express version being used.


🌐 Web query:

Are @types/express version 5.0.2 and Express version 5.1.0 compatible? What are the main breaking changes in Express v5?

💡 Result:

Yes, @types/express version 5.0.2 is compatible with Express version 5.1.0. The @types/express package provides TypeScript type definitions for Express, and version 5.0.2 aligns with the Express 5.x series, ensuring compatibility with Express 5.1.0.

Express v5 introduced several breaking changes compared to previous versions. Here are the main changes:

  1. Node.js Version Support: Express v5 drops support for Node.js versions prior to v18, requiring developers to upgrade their Node.js environments. (expressjs.com)

  2. Path Route Matching Syntax: The routing system has been updated to enhance security and clarity. Notably, sub-expression regular expressions (e.g., /:param(\\d+)) are no longer supported due to potential security vulnerabilities. Additionally, the syntax for optional parameters has changed; for example, :param? is now written as {:param}. (expressjs.com)

  3. Promise Support: Express v5 introduces improved handling of promises in middleware and route handlers. If an asynchronous function returns a rejected promise, Express will automatically pass the error to the error-handling middleware, streamlining error management. (expressjs.com)

  4. Body Parser Changes: The default behavior of the express.urlencoded() middleware has been modified. The extended option now defaults to false, which affects how nested objects are parsed. Additionally, the depth of nested objects is limited to 32 by default, addressing security concerns. (expressjs.com)

  5. Removal of Deprecated Methods: Several methods and properties that were deprecated in earlier versions have been removed in Express v5, including:

    • app.del()
    • app.param(fn)
    • req.param(name)
    • res.sendfile()
    • res.json(obj, status)
    • res.jsonp(obj, status)
    • res.redirect(url, status)
    • res.send(body, status)
    • res.send(status)
    • req.acceptsCharset()
    • req.acceptsEncoding()
    • req.acceptsLanguage()
    • res.clearCookie()
    • res.status() (now enforces stricter validation)
    • res.vary() (now enforces stricter validation)

    Developers should update their code to remove reliance on these methods and properties to ensure compatibility with Express v5. (expressjs.com)

For a comprehensive list of breaking changes and detailed migration instructions, refer to the official Express migration guide. (expressjs.com)

Citations:


Verified @types/express Compatibility with Express v5.1.0

Confirmed that @types/express@^5.0.2 is fully compatible with Express v5.1.0. No changes are needed in frontend/apps/server/package.json.

Main breaking changes in Express v5 to be aware of:

  • Requires Node.js v18 or newer
  • Updated route‐matching syntax (no sub-expression regex, :param?{:param})
  • Built-in Promise support in middleware and handlers
  • Changed express.urlencoded() defaults (extended: false, max depth 32)
  • Removal of legacy/deprecated APIs (e.g., app.del(), res.sendfile(), req.param())

For full migration details, see the official guide:
https://expressjs.com/en/guide/migrating-5.html

frontend/package.json (1)

7-8: Good monorepo script organization with recursive pnpm commands.

The recursive pnpm -r build and pnpm -r dev commands are well-suited for the monorepo structure, allowing each workspace to define its own build and dev scripts while providing convenient root-level commands. This approach addresses the earlier discussion about script placement by maintaining clear separation of concerns.

frontend/apps/server/src/cookies.ts (2)

6-6: Good explicit typing for type safety.

The explicit Record<string, string> typing for the reduce accumulator improves type safety and makes the intended data structure clear.


8-8: Explicit parameter typing improves function signature clarity.

Adding the string type annotation to the key parameter enhances type safety and function documentation.

frontend/apps/server/tsup.config.ts (1)

1-12: LGTM! Configuration aligns well with PR objectives.

The tsup configuration correctly supports the build restructuring mentioned in the PR objectives. The bundle: false setting ensures Express and other dependencies remain separate, which aligns with the need to have Express in the correct location for runtime execution.

.github/workflows/fe-cd.yml (3)

61-68: Excellent restructuring that aligns with PR objectives.

This new step correctly implements the build output restructuring mentioned in the PR objectives. By creating a unified frontend/dist/ structure and copying the server's package.json, it ensures Express dependencies can be properly installed in the deployment location.


80-89: Proper dependency installation in the correct location.

This step correctly installs dependencies in the frontend/dist/server directory, which aligns with the PR objective of ensuring Express is available in the runtime location.


66-67:

Details

✅ Verification successful

Verify that the source directories exist after build.

Ensure that frontend/apps/client/dist/ and frontend/apps/server/dist/ directories are created by the build process before this copy step runs.


🏁 Script executed:

#!/bin/bash
# Description: Verify build scripts create the expected dist directories
# Expected: Find build scripts that output to dist/ in both client and server apps

echo "Checking client build configuration..."
fd -t f "vite.config" frontend/apps/client/ --exec cat {}

echo -e "\nChecking server build configuration..."
fd -t f "tsup.config" frontend/apps/server/ --exec cat {}

echo -e "\nChecking package.json build scripts..."
cat frontend/apps/client/package.json | jq '.scripts.build'
cat frontend/apps/server/package.json | jq '.scripts.build'

Length of output: 2273


Build output directories verified – no changes required

Both the client and server builds produce their respective dist directories:

  • Client: vite.config sets outDir: 'dist', matching frontend/apps/client/dist/
  • Server: tsup.config outputs to dist, matching frontend/apps/server/dist/

The existing cp steps will succeed as-is.

frontend/apps/server/src/index.ts (6)

8-8: Good type safety improvement.

Adding explicit typing for ViteDevServer improves code clarity and IDE support.


15-17: Excellent path consolidation that supports the new build structure.

The clientPath variable with conditional logic correctly addresses the path differences between production (built output) and development environments. This aligns perfectly with the PR objectives of fixing path errors.


21-21: Good explicit typing for better type safety.

Adding explicit typing for the vite variable improves code clarity and type checking.


62-66: Improved error handling with proper type guards.

The addition of type checking with e instanceof Error before accessing error properties is a good defensive programming practice that prevents runtime errors.


83-85: Enhanced console formatting for better readability.

The multiline console.log formatting with trailing commas improves code readability and follows modern JavaScript practices.

Also applies to: 90-92


45-45:

Details

❓ Verification inconclusive

Verify route pattern change behavior.

The route pattern changed from a wildcard string '*' to a regex /(.*)/. While functionally similar, this might have subtle behavioral differences.


🏁 Script executed:

#!/bin/bash
# Description: Check if there are any specific routing requirements or tests that depend on the exact route pattern
# Expected: Find tests or documentation about routing behavior

echo "Searching for route-related tests..."
rg -A 5 -B 5 "route|middleware" frontend/apps/server/src/ || echo "No route tests found"

echo -e "\nSearching for route patterns in related files..."
rg "\*|/\(\.\*\)/" frontend/apps/ || echo "No similar patterns found"

Length of output: 9679


Verify catch-all route regex behavior

I didn’t find any existing tests or docs tied to the old '*' wildcard in frontend/apps/server/src/index.ts. Switching to the regex /(.*)/ will broadly catch all routes, but Express’s string vs. RegExp matching can differ in subtle ways. Please double-check:

  • That nested paths (e.g. /foo/bar) are still handled as before.
  • That express.static(…) continues to take precedence for asset requests.
  • That missing‐file requests don’t inadvertently fall back to your SPA handler.

Consider adding a lightweight integration test to assert both asset serving and SPA fallback behavior.
Location: frontend/apps/server/src/index.ts, line 45

Copy link
Contributor

@dioo1461 dioo1461 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM✔✔ 고생하셨습니다!!!

@hamo-o hamo-o merged commit 0a23ac7 into dev Jun 3, 2025
1 check passed
@hamo-o hamo-o deleted the bugfix/fe/build-output branch June 3, 2025 10:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

🖥️ FE Frontend

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants