原文地址

• 组织项目文件结构

  三个不同的模块： Core(核心模块), Shared(共享模块) 和 Feature(特性模块);

  • 核心模块(CoreModule):
    所有服务都应该在核心模块实现。典型的例子比如认证服务或用户服务。
  • 共享模块(ShareModule):
    所有的简单组件和管道都应该在这里实现。共享模块没有任何依赖于我们的应用程序的其余部分。比如Angular Material 等其他UI组件库的按需导入然后重导入;
  • 特性模块(FeatureModule):
    我们将为应用程序的每一个独立特性创建多个特性模块。特性模块应该只能从核心模块导入服务。如果特性模块A需要从特性模块B导入服务，可以考虑将该服务迁移到CoreModule。

在某些情况下，需要只是某些功能模块共享的服务，将它们移动到核心是没有意义的。在这种情况下，我们可以创建特殊的共享功能模块，如本文后面所述。
遵循的经验是： 我们创建的功能模块尽量不依赖其他功能模块，仅仅服务由CoreModule提供，组件由SharedModule提供

这将保持我们的代码干净，易于维护和扩展的新功能。它还减少了重构所需的工作量。如果遵循得当，我们将确信对一个功能的更改不会影响或破坏我们的应用程序的其余部分。

延迟加载:
我们应该尽可能延迟加载我们的功能模块。理论上，只有一个功能模块应该在应用程序启动时同步加载以显示初始内容。每个其他功能模块应该在用户触发导航后缓慢加载。**只有设计作为着陆的模块是需要立即加载的，其他模块应该使用懒加载**

• app 和 environments 的别名使用

  • 避免导入路径过长

     例如import { SomeService } from '../../../core/subpackage1/subpackage2/some.service'。

  • 解决方案在tsconfig.json中使用别名路径;

    #tsconfig.json
        {
          "compilerOptions": {
            "...": "reduced for brevity",
            
            "baseUrl": "src",
            "paths": {
              "@app/*": ["app/*"],
              "@env/*": ["environments/*"]
            }
          }
        }

• SASS

  • 默认情况下不添加stylePreprocessorOptions includePaths，我们可以自己设置成根目录 "./" 和 可选的 "./themes"。

    #angular.json
    {
          "apps": [
            {
              "...": "reduced for brevity",
              
              "stylePreprocessorOptions": {
                "includePaths": ["./", "./themes"]
              }
            }
          ]
    }

• 构建阶段

  • Target Production
    这是一个标志能使代码压缩，以及还有很多默认的有用的构建标志。使用如下：

    --environment prod —使用 environment.prod.ts 文件设置环境变量
    --aot —预编译，提前编译. 这将在未来的Angular CLI是默认设置，但是现在我们必须手动启动。
    --output-hashing all — 将生成的文件的散列内容添加到文件名中，以方便浏览器缓存破坏（文件内容的任何更改都会导致不同的哈                    
    希值，因此浏览器被迫加载新版本的文件）
    --extract-css true — 将所有的css提取到到单独的样式表文件
    --sourcemaps false — 禁用source maps的生成
    --named-chunks false — 禁用使用可读的名字，用数字替代

  • Other useful flags

    --build-optimizer — 新的功能，导致更小的捆绑，但更长的构建时间，所以慎用！（将来也应该默认启用）
    --vendor-chunk — 将所有第三方（库）代码提取到单独的块中

    去官方文档检查其他有用的配置项，也许在个人项目中用得上。

• 使用标准的提交信息 & 自动生成更新日志

  • standard-version

    这个工具根据 [Conventional-Commits-specification][3] 把所有提交自动生成和更新changelog.md文件
    并且正确地确定我们项目的新版本。

  • 如何使用

    npm install -D standard-version, 然后添加脚本"release": "standard-version"到package.json文件中。
    例如："release": "standard-version && git push — follow-tags origin master && npm publish"