如何构建Polymer 2项目结构？组件依赖管理求助

Hey there! Let's break down how to structure your Polymer 2 + Bower setup when you've got multiple components (some full apps) in separate Git repos. I've navigated similar setups before, so here's a practical, scalable approach:

First, treat every component and full app as a standalone, versioned package. Each repo should be self-contained—meaning it can be built, tested, and used independently without relying on external repo structure. This keeps your codebase modular and easy to maintain.

Stick to a consistent structure across every repo (whether it's a reusable component or a full application) to avoid confusion:

• bower.json: Your package manifest. Define all dependencies here—Polymer core elements, your own custom components, and third-party tools. Use semantic version ranges (like ^2.0.0) to balance stability and flexibility.
• src/: For components, store your element definition files (e.g., my-custom-button.html). For full apps, this holds your app shell, views, and core logic.
• demo/: Add a demo page here to showcase the component/app in action. It’s great for testing during development and for documentation purposes.
• test/: Include unit and integration tests using Polymer’s web-component-tester to maintain quality across all your packages.
• index.html: The entry point—load your demo here for components, or your main app shell for full applications.
• .gitignore: Add bower_components/ to this file—never commit dependencies to Git; let Bower handle installation per repo.

When your components or apps depend on each other, follow these rules to keep things smooth:

• Reference internal dependencies in bower.json using their Git repo URL and a specific version tag. For example:

  "dependencies": {
    "my-shared-utils": "git@github.com:your-username/my-shared-utils.git#v1.1.0"
  }
  

• Use semantic versioning (SemVer) for all your repos. Tag every release with vX.Y.Z (e.g., v1.0.0 for initial stable release, v1.1.0 for minor features, v2.0.0 for breaking changes). This lets you lock dependencies to stable versions and avoid unexpected breaks.
• For local development (when you need to tweak a dependent component while working on an app), use bower link:
  1. In the dependent component’s repo, run bower link
  2. In your app’s repo, run bower link my-shared-utils
     This creates a symlink between the two repos, so any changes you make to the component are immediately reflected in the app.

• Organize all your repos in a single parent directory on your machine (e.g., polymer-projects/) to keep things tidy.
• Automate repetitive tasks with npm scripts or a tool like Gulp. For example, add a serve script to your package.json that runs polymer serve to spin up a local dev server:

  "scripts": {
    "serve": "polymer serve --open"
  }
  

• Test each package independently first before integrating it into other apps/components. This catches issues early.

• Don’t use absolute paths: Stick to relative paths or let Bower’s dependency resolution handle imports (e.g., import '../polymer/polymer.html'; or import 'my-shared-utils/src/utils.html';).
• Avoid circular dependencies: If Component A depends on B and B depends on A, extract the shared logic into a third, independent component.
• Don’t skip versioning: Without tagged releases, you’ll struggle to track which component versions work with which apps, leading to debugging headaches.

内容的提问来源于stack exchange，提问作者Joern Turner