mcpField
D
da-cli

da-cli

github.com/stahura開発24190 回インストール26 週間前に更新
リポジトリ

da-cli について

da-cliは、Domoカスタムアプリ開発者向けのコマンドラインツールです。プロジェクトのひな形やコードを生成し、環境別のmanifestを管理できます。

主な機能

  1. 01Vite、React 18、TypeScriptのアプリ作成
  2. 02コンポーネントとひな形コードの生成
  3. 03環境別manifestの管理
  4. 04カスタムテンプレートへの対応

活用シーン

  1. 01新しいDomoカスタムアプリの開始
  2. 02テストとスタイルを含むコンポーネントの生成
  3. 03開発・ステージング・本番用manifestの準備

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/stahura/domo-ai-vibe-rules --skill da-cli

インストール後、Claude Code で/da-cliを入力して読み込まれたか確認します。

詳細

@domoinc/da CLI - アプリのスキャフォールディングとコード生成

DA CLI(@domoinc/da)は、Domo のカスタムアプリをスキャフォールディングし、ボイラープレートコードを生成するコマンドラインツールです。新しい Domo アプリの作成やコンポーネントの生成には、推奨される方法です。

目的

DA CLI では、次のことができます。

  • プロジェクトのスキャフォールディング - 正しい構成(Vite + React 18 + TypeScript)で新しい Domo アプリを作成します
  • コード生成 - 適切な Domo パターンに沿って、コンポーネント、リデューサーなどのボイラープレートを生成します
  • マニフェスト管理 - 環境ごとのマニフェスト設定を管理します
  • ベストプラクティス - プロジェクトが最初から Domo の規約に従うようにします

インストール

# Install globally
pnpm add -g @domoinc/da

# Or with npm
npm install -g @domoinc/da

新しいアプリの作成

# Create new Domo app (recommended - Vite + React 18 + TypeScript)
da new my-app-name
cd my-app-name

# With custom template
da new my-app --template @myorg/custom-template
da new my-app --template github.com/user/repo
da new my-app --template ./local-template

作成されるプロジェクト構成:

my-app/
├── public/
│   ├── manifest.json      # Domo app configuration
│   └── thumbnail.png      # App icon in Domo
├── src/
│   ├── components/        # React components
│   ├── reducers/          # Redux slices (if using)
│   ├── services/          # API service layers
│   ├── types/             # TypeScript definitions
│   └── index.tsx          # App entry point
├── package.json
└── vite.config.ts

コード生成

# Generate component with styles, tests, and Storybook
da generate component MyComponent
# Creates:
#   src/components/MyComponent/MyComponent.tsx
#   src/components/MyComponent/MyComponent.module.scss
#   src/components/MyComponent/MyComponent.test.tsx
#   src/components/MyComponent/MyComponent.stories.tsx

# Shorthand
da g component MyComponent

# Generate Redux slice (auto-imports to store)
da generate reducer myFeature
# Creates: src/reducers/myFeature/slice.ts

# Shorthand
da g reducer myFeature

マニフェスト管理

DA CLI では、複数の Domo 環境(dev、staging、prod)の管理に役立ちます。

# Create environment-specific manifest overrides
da manifest instance.prod "Production on customer.domo.com"
da manifest instance.dev "Development on dev.domo.com"

# Apply an override before publishing
da apply-manifest instance.prod
yarn upload

オーバーライドファイルの構成:

{
  "instance.prod": {
    "description": "Production environment",
    "manifest": {
      "id": "prod-app-design-id",
      "proxyId": "prod-card-id"
    }
  }
}

生成されたアプリ(Lovable/v0)の Domo への変換

多くの開発者が、Lovable、v0 などの AI ツールや同様の LLM ベースのジェネレーターを使ってアプリのプロトタイプを作成しています。しかし、これらのツールは通常、Domo のクライアントサイドのみのアーキテクチャと互換性のないサーバーサイドレンダリング(SSR)を使ったアプリを生成します。

変換時の課題

生成されたアプリには、次のものが含まれていることがよくあります。

  • サーバーサイドレンダリング(Next.js、Remix、SvelteKit、Nuxt)
  • API ルート(pages/api/ または app/api/ ディレクトリ)
  • サーバーサイドのデータ取得(getServerSideProps、ローダーなど)
  • フレームワーク固有のルーティング(Next.js App Router、Remix のルート)

Domo アプリは、次の要件を満たす必要があります。

  • 純粋なクライアントサイド React - サーバーサイドレンダリングは使用しません
  • 静的ファイルベース - Domo が提供するのは静的ファイルのみです
  • Domo API との統合 - バックエンドエンドポイントの代わりに、domo.get()、Query、AppDBClient などを使用します
推奨される変換パターン

DA CLI は変換ツールではありません。アプリを自動的に変換することはできません。ただし、参考となる構成や出発点として利用できます。

ステップ 1:参考構成を生成する
# Create a fresh Domo app to use as reference
da new my-converted-app
cd my-converted-app

# This gives you the correct structure to compare against
ステップ 2:SSR コードを検出して削除する

SSR を示すものを確認します。

  • getServerSideProps、getStaticProps(Next.js)
  • loader、action 関数(Remix)
  • +page.server.js、+server.js(SvelteKit)
  • pages/api/ または app/api/ ディレクトリ
  • サーバーサイドでの process.env の使用
  • コンポーネント内のデータベース接続

対応: サーバーサイドのコードをすべて削除します。Domo アプリはすべてブラウザー内で動作します。

ステップ 3:データ取得を置き換える

変換前(Next.js の例):

// ❌ Server-side data fetching
export async function getServerSideProps() {
  const res = await fetch('https://api.example.com/data');
  const data = await res.json();
  return { props: { data } };
}

// ❌ API route
// pages/api/users.ts
export default async function handler(req, res) {
  const users = await db.users.findMany();
  res.json(users);
}

変換後(Domo):

// ✅ Client-side with Domo APIs
import domo from 'ryuu.js';
import Query from '@domoinc/query';
import { AppDBClient } from '@domoinc/toolkit';

// Fetch from Domo dataset
const data = await domo.get('/data/v1/sales');

// Or use Query API for filtered/aggregated data
const summary = await new Query()
  .select(['region', 'sales'])
  .groupBy('region', { sales: 'sum' })
  .fetch('sales-dataset');

// Or use AppDB for document storage
const tasksClient = new AppDBClient.DocumentsClient('Tasks');
const tasks = await tasksClient.get();
ステップ 4:ルーティングを更新する

変換前(Next.js):

// ❌ Next.js routing
import Link from 'next/link';
<Link href="/dashboard">Dashboard</Link>

変換後(Domo):

// ✅ HashRouter for client-side routing
import { HashRouter, Routes, Route } from 'react-router-dom';
import domo from 'ryuu.js';

// Use HashRouter (works without server rewrites)
<HashRouter>
  <Routes>
    <Route path="/" element={<Home />} />
    <Route path="/dashboard" element={<Dashboard />} />
  </Routes>
</HashRouter>

// For Domo navigation, use domo.navigate()
domo.navigate('/page/123456789');
ステップ 5:ビルド設定を修正する

変換前(Next.js):

// next.config.js
module.exports = {
  // Next.js config
}

変換後(Domo - Vite):

// vite.config.js
import { defineConfig } from 'vite';
import react from '@vitejs/plugin-react';

export default defineConfig({
  base: './',  // CRITICAL: Relative paths for Domo
  plugins: [react()],
});
ステップ 6:コンポーネントを移植する

DA CLI で正しい構成の新しいコンポーネントを生成してから、ロジックを移植します。

# Generate component structure
da generate component SalesChart

# Copy component logic from generated app
# Replace data fetching with Domo APIs
# Update imports and dependencies
DA CLI でできること

✅ 参考となる構成 - Domo アプリの正しい構成を確認できます
✅ コンポーネントの生成 - 適切な構成のコンポーネントを作成できます
✅ パターンの例 - Domo の規約を確認できます
✅ 新規作成 - 変換が複雑すぎる場合は、新しく作成してロジックを移植できます

DA CLI でできないこと

❌ 自動変換はできません - SSR をクライアントサイドに変換できません
❌ 移行ウィザードはありません - 段階的に変換するツールはありません
❌ コード変換はできません - フレームワーク固有のコードを書き換えることはできません
❌ API 移行はできません - バックエンド呼び出しを自動的に置き換えることはできません

変換チェックリスト
  • SSR コードをすべて検出して削除する
  • API ルート(pages/api/、app/api/)を削除する
  • バックエンドへの fetch() 呼び出しを Domo API に置き換える
  • ルーティングを HashRouter に更新する
  • Vite を base: './' で設定する
  • 環境変数を置き換える(代わりに Domo API を使用する)
  • インポートを更新する(Next.js/Remix 固有のものを削除する)
  • すべてのデータ取得が Domo API で動作することをテストする
  • アプリがローカルでビルドされ、実行されることを確認する
  • アプリを Domo に公開し、プラットフォーム上でテストする
例:シンプルなダッシュボードの変換

変換前(Lovable/Next.js):

// pages/dashboard.tsx
export async function getServerSideProps() {
  const sales = await fetch('http://api.company.com/sales').then(r => r.json());
  return { props: { sales } };
}

export default function Dashboard({ sales }) {
  return <div>{/* Render sales data */}</div>;
}

変換後(Domo):

// src/components/Dashboard/Dashboard.tsx
import { useEffect, useState } from 'react';
import domo from 'ryuu.js';

export default function Dashboard() {
  const [sales, setSales] = useState([]);

  useEffect(() => {
    // Fetch from Domo dataset instead of backend
    domo.get('/data/v1/sales').then(setSales);
  }, []);

  return <div>{/* Render sales data */}</div>;
}

参考情報:CODE_BLOCKS_DA_CLI.md

追加するコードブロック:DA CLI と変換ガイド

「ビルドとデプロイのワークフロー」セクションの後、「ベースパスの設定」セクションの前にこのセクションを追加してください。


@domoinc/da CLI - アプリのスキャフォールディングとコード生成

DA CLI(@domoinc/da)は、Domo カスタムアプリのスキャフォールディングとボイラープレートコードの生成に使用するコマンドラインツールです。新しい Domo アプリの作成やコンポーネントの生成には、推奨される方法です。

目的

DA CLI は以下を提供します:

  • プロジェクトのスキャフォールディング - 正しい構成(Vite + React 18 + TypeScript)で新しい Domo アプリを作成します
  • コード生成 - 適切な Domo のパターンに沿って、コンポーネント、リデューサー、その他のボイラープレートコードを生成します
  • マニフェスト管理 - 環境ごとのマニフェスト設定を管理します
  • ベストプラクティス - プロジェクトが最初から Domo の規約に従うようにします
インストール
# Install globally
pnpm add -g @domoinc/da

# Or with npm
npm install -g @domoinc/da
新しいアプリの作成
# Create new Domo app (recommended - Vite + React 18 + TypeScript)
da new my-app-name
cd my-app-name

# With custom template
da new my-app --template @myorg/custom-template
da new my-app --template github.com/user/repo
da new my-app --template ./local-template

作成されるプロジェクト構成:

my-app/
├── public/
│   ├── manifest.json      # Domo app configuration
│   └── thumbnail.png      # App icon in Domo
├── src/
│   ├── components/        # React components
│   ├── reducers/          # Redux slices (if using)
│   ├── services/          # API service layers
│   ├── types/             # TypeScript definitions
│   └── index.tsx          # App entry point
├── package.json
└── vite.config.ts
コード生成
# Generate component with styles, tests, and Storybook
da generate component MyComponent
# Creates:
#   src/components/MyComponent/MyComponent.tsx
#   src/components/MyComponent/MyComponent.module.scss
#   src/components/MyComponent/MyComponent.test.tsx
#   src/components/MyComponent/MyComponent.stories.tsx

# Shorthand
da g component MyComponent

# Generate Redux slice (auto-imports to store)
da generate reducer myFeature
# Creates: src/reducers/myFeature/slice.ts

# Shorthand
da g reducer myFeature
マニフェスト管理

DA CLI を使用すると、複数の Domo 環境(dev、staging、prod)を管理できます。

# Create environment-specific manifest overrides
da manifest instance.prod "Production on customer.domo.com"
da manifest instance.dev "Development on dev.domo.com"

# Apply an override before publishing
da apply-manifest instance.prod
yarn upload

オーバーライドファイルの構成:

{
  "instance.prod": {
    "description": "Production environment",
    "manifest": {
      "id": "prod-app-design-id",
      "proxyId": "prod-card-id"
    }
  }
}

生成されたアプリ(Lovable/v0)の Domo への変換

多くの開発者は、Lovable、v0 などの AI ツールや、LLM ベースの同様のジェネレーターを使用してアプリのプロトタイプを作成します。しかし、これらのツールは通常、サーバーサイドレンダリング(SSR)を使用するアプリを生成するため、Domo のクライアントサイドのみのアーキテクチャと互換性がありません。

変換時の課題

生成されたアプリには、次のものが含まれることがよくあります。

  • サーバーサイドレンダリング(Next.js、Remix、SvelteKit、Nuxt)
  • API ルート(pages/api/ または app/api/ ディレクトリ)
  • サーバーサイドのデータ取得(getServerSideProps、ローダーなど)
  • フレームワーク固有のルーティング(Next.js App Router、Remix routes)

Domo アプリは次の要件を満たす必要があります。

  • 純粋なクライアントサイドの React - サーバーレンダリングは使用しません
  • 静的ファイルベース - Domo が提供するのは静的ファイルのみです
  • Domo API との統合 - バックエンドエンドポイントの代わりに、domo.get()、Query、AppDBClient などを使用します
推奨される変換パターン

DA CLI は変換ツールではありません。アプリを自動的に変換することはありません。ただし、参照用の構成や出発点として使用できます。

ステップ 1:参照用の構成を生成する
# Create a fresh Domo app to use as reference
da new my-converted-app
cd my-converted-app

# This gives you the correct structure to compare against
ステップ 2:SSR コードを検出して削除する

SSR の兆候を確認します:

  • getServerSideProps、getStaticProps(Next.js)
  • loader、action 関数(Remix)
  • +page.server.js、+server.js(SvelteKit)
  • pages/api/ または app/api/ ディレクトリ
  • サーバーサイドでの process.env の使用
  • コンポーネント内のデータベース接続

対応: サーバーサイドのコードをすべて削除します。Domo アプリはすべてブラウザー内で実行されます。

ステップ 3:データ取得を置き換える

変更前(Next.js の例):

// ❌ Server-side data fetching
export async function getServerSideProps() {
  const res = await fetch('https://api.example.com/data');
  const data = await res.json();
  return { props: { data } };
}

// ❌ API route
// pages/api/users.ts
export default async function handler(req, res) {
  const users = await db.users.findMany();
  res.json(users);
}

変更後(Domo):

// ✅ Client-side with Domo APIs
import domo from 'ryuu.js';
import Query from '@domoinc/query';
import { AppDBClient } from '@domoinc/toolkit';

// Fetch from Domo dataset
const data = await domo.get('/data/v1/sales');

// Or use Query API for filtered/aggregated data
const summary = await new Query()
  .select(['region', 'sales'])
  .groupBy('region', { sales: 'sum' })
  .fetch('sales-dataset');

// Or use AppDB for document storage
const tasksClient = new AppDBClient.DocumentsClient('Tasks');
const tasks = await tasksClient.get();
ステップ 4:ルーティングを更新する

変更前(Next.js):

// ❌ Next.js routing
import Link from 'next/link';
<Link href="/dashboard">Dashboard</Link>

変更後(Domo):

// ✅ HashRouter for client-side routing
import { HashRouter, Routes, Route } from 'react-router-dom';
import domo from 'ryuu.js';

// Use HashRouter (works without server rewrites)
<HashRouter>
  <Routes>
    <Route path="/" element={<Home />} />
    <Route path="/dashboard" element={<Dashboard />} />
  </Routes>
</HashRouter>

// For Domo navigation, use domo.navigate()
domo.navigate('/page/123456789');
ステップ 5:ビルド設定を修正する

変更前(Next.js):

// next.config.js
module.exports = {
  // Next.js config
}

変更後(Domo - Vite):

// vite.config.js
import { defineConfig } from 'vite';
import react from '@vitejs/plugin-react';

export default defineConfig({
  base: './',  // CRITICAL: Relative paths for Domo
  plugins: [react()],
});
ステップ 6:コンポーネントを移植する

DA CLI を使って正しい構成の新しいコンポーネントを生成し、その後ロジックを移植します。

# Generate component structure
da generate component SalesChart

# Copy component logic from generated app
# Replace data fetching with Domo APIs
# Update imports and dependencies
DA CLI が役立つこと

✅ 参照用の構成 - Domo アプリの正しい構成を示します
✅ コンポーネントの生成 - 適切な構成のコンポーネントを作成します
✅ パターンの例 - Domo の規約を説明します
✅ 新規作成 - 変換が複雑すぎる場合は、新しく作成してロジックを移植できます

DA CLI が行わないこと

❌ 自動変換なし - SSR をクライアントサイドに変換しません
❌ 移行ウィザードなし - ステップごとの変換ツールはありません
❌ コード変換なし - フレームワーク固有のコードを書き換えません
❌ API 移行なし - バックエンド呼び出しを自動的に置き換えません

完全な変換チェックリスト
  • すべての SSR コードを検出して削除する
  • API ルート(pages/api/、app/api/)を削除する
  • バックエンドへの fetch() 呼び出しを Domo API に置き換える
  • ルーティングを HashRouter に更新する
  • base: './' を指定して Vite を設定する
  • 環境変数を置き換える(代わりに Domo API を使用する)
  • インポートを更新する(Next.js/Remix 固有のものを削除する)
  • すべてのデータ取得が Domo API で動作することをテストする
  • アプリをローカルでビルドして実行できることを確認する
  • Domo に公開し、プラットフォーム上でテストする
例:シンプルなダッシュボードの変換

元の構成(Lovable/Next.js):

// pages/dashboard.tsx
export async function getServerSideProps() {
  const sales = await fetch('http://api.company.com/sales').then(r => r.json());
  return { props: { sales } };
}

export default function Dashboard({ sales }) {
  return <div>{/* Render sales data */}</div>;
}

変換後(Domo):

// src/components/Dashboard/Dashboard.tsx
import { useEffect, useState } from 'react';
import domo from 'ryuu.js';

export default function Dashboard() {
  const [sales, setSales] = useState([]);

  useEffect(() => {
    // Fetch from Domo dataset instead of backend
    domo.get('/data/v1/sales').then(setSales);
  }, []);

  return <div>{/* Render sales data */}</div>;
}


参考資料:PR_DA_CLI_DESCRIPTION.md

DA CLI のドキュメントと Lovable/v0 変換ガイドの追加

概要

この PR では、@domoinc/da CLI ツールの包括的なドキュメントと、Lovable/v0(または同様の LLM 生成)アプリを動作する Domo アプリに変換するためのガイドを追加します。

追加内容

  1. DA CLI のドキュメント

    • DA CLI の目的と機能
    • インストールとセットアップ
    • コード生成コマンド(コンポーネント、リデューサー)
    • 複数の環境向けのマニフェスト管理
    • プロジェクト構成の概要
  2. 生成されたアプリの変換ガイド

    • Lovable/v0 アプリを Domo に変換する手順
    • DA CLI を参考にする推奨パターン
    • よくある非互換性とその修正方法
    • データ取得の移行パターン
    • ルーティングとビルド設定の更新

重要な理由

多くの開発者は Lovable や v0 などの AI ツールを使ってアプリのプロトタイプを生成しますが、これらのツールはサーバーサイドレンダリングを使用する Next.js/Remix アプリを生成するため、クライアントサイドのみの Domo アーキテクチャとは互換性がありません。このガイドでは、変換の明確な手順を紹介します。

主なポイント

  • DA CLI の目的:DA CLI は変換ツールではなくスキャフォールディングツールであることを説明しますが、参考となる構成として利用できます
  • 変換パターン:コンポーネントとロジックを手動で移植する手順を説明します
  • SSR の検出:サーバーサイドコードを検出して削除する重要性を改めて示します
  • API の移行:バックエンドへの呼び出しを Domo API に置き換えるための明確なパターンを示します

場所

「Build & Deploy Workflow」セクションの後、「Base Path Configuration」の前に追加しました。


参考資料:PR_DA_CLI_SUGGESTIONS.md

PR 提案:DA CLI のドキュメントと変換ガイド

概要

この PR では、@domoinc/da CLI ツールのドキュメントと、Lovable/v0(または同様の LLM 生成)アプリを動作する Domo カスタムアプリに変換するための包括的なガイドを追加します。

背景

DA CLI のドキュメント不足

現在の .cursorrules ファイルでは DA CLI に簡単に触れているだけで、以下について説明していません。

  • DA CLI とは何か、なぜ存在するのか
  • そのすべての機能(コード生成、マニフェスト管理)
  • 他のセットアップ方法との違い
  • 手動セットアップと比べて、いつ使用すべきか
変換ガイドの必要性

多くの開発者は AI ツール(Lovable、v0 など)を使ってアプリのプロトタイプを生成しますが、これらのツールが生成するものは以下のとおりです。

  • SSR を使用する Next.js アプリ(Domo と非互換)
  • API ルート(Domo にはバックエンドがありません)
  • フレームワーク固有のパターン(Domo に相当するものへの置き換えが必要)

現在、こうしたアプリの変換方法に関するガイダンスがありません。この PR はその不足を補います。

影響の評価

価値の高い追加内容:

  • DA CLI のドキュメント - 推奨ツールについて開発者が理解するのに役立ちます
  • 変換ガイド - 生成されたアプリを扱う開発者の試行錯誤にかかる時間を大幅に削減します
  • パターンのガイダンス - 一般的なフレームワークからの明確な移行経路を示します

開発者にとってのメリット:

  • DA CLI をいつ、どのように使うかを理解できます
  • 生成されたアプリを変換するための明確な手順を把握できます
  • よくある問題(SSR、API ルート、ルーティング)を回避できます
  • DA CLI でできることとできないことを把握できます

追加する場所の提案

「Build & Deploy Workflow」セクションの後、「Base Path Configuration」の前に挿入します。この配置が適切な理由は次のとおりです。

  1. プロジェクトのセットアップとワークフローに関する内容である
  2. 変換は開発プロセスの一部である
  3. 技術的な設定の詳細より前に位置する

コンテンツ構成

追加内容:

1. DA CLI — 目的と機能
  • DA CLI とは何か(スキャフォールディングとコード生成のツール)
  • インストールと基本的な使い方
  • コード生成コマンド
  • マニフェスト管理
  • 作成されるプロジェクト構成
2. 生成したアプリをDomo向けに変換する
  • 変換時の課題(SSR、API ルートなど)
  • 推奨される変換パターン
  • 手順:
    1. DA CLI を使用して参照用の構成を生成する
    2. SSR コードを検出して削除する
    3. データ取得をDomo APIに置き換える
    4. ルーティングを更新する(HashRouter)
    5. ビルド設定を修正する
  • DA CLIでできること(参照用の構成、コンポーネント生成)
  • DA CLIでできないこと(自動変換は行いません)

主なポイント

含まれる重要な情報:
  • DA CLIは変換ツールではありません — 重要な補足説明
  • 変換時の参照としてDA CLIを使用する — 推奨される変換パターン
  • SSRの検出 — サーバーサイドコードに関する既存の警告を補強
  • API移行パターン — バックエンド呼び出しを置き換える明確な例
  • 手順 — 実行可能な変換ワークフロー
コード例:
  • DA CLIのインストールと使い方
  • コンポーネント生成の例
  • 環境ごとのマニフェスト管理
  • 変換パターンの例
  • データ取得の移行(Next.js → Domo API)

テストに関する注記

このドキュメントは、以下に基づいています。

  • DA CLIの公式ドキュメントにあるパターン
  • Lovable/v0アプリでよくある変換シナリオ
  • Domoアプリのアーキテクチャに関するベストプラクティス
  • 既存のSSR検出に関する警告との統合

更新するファイル

  • .cursorrules — DA CLIのセクションと変換ガイドを追加

コメント