使用styled-components的S.命名导入规范时多来源导入冲突如何处理

常用解决方案如下： #

• 按来源区分命名空间别名
  本地组件的样式文件保持原有习惯用S作为别名，其他来源的样式组件按模块/用途起不同别名即可。比如来自Foo组件的样式可以写import * as FooS from "../shared/Foo/Foo"，使用时通过FooS.Foo引用，既保留了命名空间区分业务组件的作用，也不会和本地的S.BarWrapper冲突。如果有多个共享模块的样式，也可以按模块名定义别名，比如UserS、CardS等，可读性更强。
• 混合导入模式
  不需要强制所有样式组件都走命名空间导入。本地高频使用的样式保留import * as S from "./Bar.styles"的写法，单个引用的共享样式组件直接用命名导入即可：import { Foo } from "../shared/Foo/Foo"。本身共享样式组件的命名都是全局唯一的，不会和本地业务组件重名，直接导入使用成本更低。
• 统一共享样式入口
  如果项目里公共样式组件很多，可以在共享组件目录下新增统一的样式导出入口，比如src/components/shared/styles/index.ts，把所有通用样式组件都汇总到这个入口导出。后续使用时直接import * as SharedS from "@/components/shared/styles"，所有通用样式都在SharedS命名空间下，和本地的S完全隔离，维护也更方便。
• 调整命名空间约定
  如果团队要求所有样式组件都必须带命名空间前缀，可以调整统一的命名规则：比如本地组件的样式统一用LocalS作为别名，共享样式统一用SharedS，第三方UI库的自定义样式用UIS，从根源上避免不同来源的样式命名空间冲突。

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