22 个版本 (8 个破坏性更新)

新功能 0.14.0 2024年8月2日
0.13.2 2024年7月23日
0.12.0 2024年7月18日
0.7.0 2024年3月22日
0.6.5 2023年9月24日

2521魔法豆

Download history 1/week @ 2024-05-16 129/week @ 2024-05-23 2/week @ 2024-05-30 4/week @ 2024-06-06 552/week @ 2024-06-20 24/week @ 2024-06-27 36/week @ 2024-07-04 529/week @ 2024-07-11 476/week @ 2024-07-18 116/week @ 2024-07-25 120/week @ 2024-08-01

每月1,241 次下载

Apache-2.0

60KB
1.5K SLoC

loam-cli

使用 Loam SDK 编写的智能合约构建器,从前端管理智能合约依赖项,初始化新的 loam 项目。

Loam CLI 包含三个主要命令

  • loam init - 生成一个 Loam 前端,其中包含一个 environments.toml 文件,该文件描述了团队针对每个环境构建的网络设置、账户和合约。
  • loam build - 一个包含两个构建过程的工具
    • 构建智能合约。本质上,这是一个包装了 soroban build 的工具,可以用于构建任何 Soroban 项目的合约。像 soroban build 一样,它将使用建议的设置来构建合约,这意味着它相当于某种 cargo build --target wasm32-unknown-unknown 的简写。但在其之上,loam build 还将找到所有 Loam 依赖项,解决相互依赖关系,并按正确顺序构建它们。
    • 构建前端客户端。如果项目包含一个 environments.toml 文件,loam build 将匹配由 LOAM_ENV 环境变量指定的环境(对于 loam build,默认是 production)到一个可预测的起始状态。它将您依赖的合约(合约依赖)转换为前端包(NPM依赖),使您的前端应用程序达到可以构建或运行自己的开发服务器的状态。这将以尽可能低干扰的方式进行(例如,如果合约已经部署,它们是否使用了正确的Wasm哈希?是否需要延长它们的TTL?它会更新这些内容,而不是每次都重新部署。)
  • loam dev - 监控 contractsenvironments.toml 的变化,并在需要时重新运行 loam build。它还默认设置为 LOAM_ENV=development,而不是 production

使用 loam init 入门

  1. 安装 loam cli: cargo install loam-cli
  2. 要创建一个 loam 项目,运行 loam init <PROJECT_PATH>。这将创建一个位于提供的 <PROJECT_PATH>Loam 前端 项目。
  3. 在您的项目目录中运行以下命令,以使用两个示例合约启动一个 loam 项目
  • cp.env.example.env
  • npm install
  • npm run dev

loam devloam build 深入解析

loam devloam build 在本质上工作相同,只是一个是用于测试,另一个是用于生产。

loam build

loam dev 是将合约依赖转换为NPM依赖的工具链。它将您依赖的合约(合约依赖)转换为前端包(NPM依赖),使您的应用程序达到可以构建或运行自己的开发服务器的状态,例如 astro dev。(此模板使用 Astro,但 loam-cli 本身对您如何运行 JavaScript 前端不敏感。它也可以与 next dev 或 Svelte 或 Vue 或任何其他 JavaScript 前端工具一起使用。)

以下是 loam build 将执行的所有操作的完整列表

  1. 默认为 production 环境。此环境设置可以通过 --env 标志或通过 LOAM_ENV 环境变量进行更改。

  2. 检查 environments.toml 文件并将内容设置为指定的可预测起始状态

    flowchart TD
      A[loam dev] -->|network| B(run-locally?)
      B -->|yes| C[start]
      B -->|no| D[check]
      A -->|accounts| E(mainnet?)
      E -->|yes| F[check]
      E -->|no| G[create & fund]
      A -->|contracts| H(local?)
      H -->|yes| I(workspace = true?)
      I -->|yes| J[build, deploy, init]
      I -->|no| K[spoon]
      H -->|no| L[check]
      J --> M[bind & import]
      K --> M
      L --> M
    
    • 连接到指定的网络,或使用 soroban network start 运行它
    • 创建和/或资助账户 → 在主网上,将检查账户是否存在并且有资金
    • 对于指定的合约
      • 对于使用 本地网络 的环境
        • 对于具有 workspace = true 的合约
          • 构建 & 部署 合约,保存 ID 以便在后续运行时验证合约已部署并更新它们(如果需要)。
          • 初始化 合约:运行任何指定的 init 命令(请参阅下面的 environments.toml
        • [超出初始拨款范围]:对于指定了 环境地址at-ledger-sequence 的合同
          • 将指定合同的状态,在指定的账本序列时间,导入到当前环境网络。
      • 对于使用 futurenettestnetmainnet 或其他实时网络的 环境
        • 检查 合同是否存在于该网络。注意:Loam 目前还没有计划帮助部署合同。它只检查你是否已成功自行部署。
      • 对于所有环境
        • 绑定 合同
          • 为每个合同运行 soroban contract bindings typescript
          • 将每个生成的库保存到 git 忽略的 packages/*,它是 NPM 工作区 的一部分,使用 environments.toml 中指定的名称
          • 为每个合同修改 networks 导出,包括 environments.toml 中指定的所有网络
        • 导入 合同以在前端使用。即,为每个合同创建 git 忽略的 src/contracts/* 文件,导入 Contract 类和 networks 对象,并导出当前环境网络的实例化版本。

loam dev

loam devloam build 的包装,但会

  1. 默认为 开发 环境
  2. 自动监视 contracts/*environments.toml 的更改,并在更改时重新运行 loam build

loam build 建议

我们建议每个前端都有独立的合同依赖项,部署在不同的网络上。

因此,你应该为主网构建你的前端版本,并在根域名上托管,例如,example.com。然后为测试网构建一个单独的版本,并在不同的域名上托管,例如 staging.example.com

依赖项

~54–77MB
~1.5M SLoC