Web App典型场景下spm的使用疑问

[StuPig]

典型场景：

# 传统开发中的典型目录结构
.
├── assets # common modules and the third-party libaries
│   ├── backbone
│   │   └── 0.9.2
│   │       ├── backbone-min.js
│   │       └── backbone.js
│   ├── seajs
│   │   └── 1.2.1
│   │       ├── sea-min.js
│   │       └── sea.js
│   ├── ...
│   ├── plugin-tracker.js
│   ├── ... # common seajs plugins as plugin-tracker
│   └── css
│       └── reset.css
├── css
├── imgs
├── index.html
└── js  # a lot of app's custom modules
    ├── bootstrap.js
    ├── models
    │   └── nearbydeals.js
    ├── template.js
    ├── views
    │   └── nearbydeals.js
    └── ...

assets目录下主要存放不经常变的通用模块、通用资源文件和第三方类库
js下存放很多app相关自定义的业务、功能模块

开发时，简单划分好类似上图的文件结构，本地基本不需要搭什么环境，就可以快速上手开发和迭代。

使用问题

seajs和spm使用时间不长，以下可能有失偏颇

1. spm对于目录结构的严格要求
   spm要求模块是独立的，并规定了相应的目录结构，同时，spm基于此严格的模块拆分，提供了source``install``deploy相关功能，这些都很赞（目前流行的前端自动化库grunt也是如此）。但是，在这种传统的网站或者Web App开发中，太多的自定义的频繁改动的业务、功能模块，如果他们都按照spm规定的目录结构做的话，将会很复杂，并且难于维护。很难想象，上图中js下的文件会变得多么冗余。目前的这种严格目录结构，对于通用的模块开发（比方说aralejs）优势多多，对于这种小型的传统的业务开发却并不友好
2. spm(v0.9.11)build对于多层目录的支持不友好
   因为上一点spm对于目录结构的要求，我考虑将js/整个作为一个spm结构中的模块，这样js目录结构变为：

        └── js  # a lot of app's custom modules
            ├── dist
            ├── package.json
            └── src
                ├── bootstrap.js
                ├── models
                │   └── nearbydeals.js
                ├── template.js
                ├── views
                │   └── nearbydeals.js
                └──  ...

我的需求是对js/目录和其子目录下的每个文件只压缩不合并，这时我的package.json的output只能这样去写:

    "output": {
      "bootstrap.js": ".",
      "template.js": ".",
      "models/nearbydeals.js": ".",
      "views/nearbydeals.js": ".",
      ...
    }

了解到v0.9.12中将加入批量输出，不知是否支持嵌套目录下的批量输出

1. 开发和上线的路径问题
   与issues #310中 @yuanyan 的需求类似，开发环境希望尽可能的和线上保持一致。通过spm deploy的确可以解决这个问题。但是项目开发和上线时兼顾的规则变多了，就失去qucik-and-dirty的感觉。很多时候，大家可能并不是去开发像aralejs这种大型模块化组件库，而只是去快速的开发应用。

对spm的期望：

1. 可繁可简，伸缩自如
   像seajs一样提供简单的配置，让开发者可以快速上手使用基本功能。不仅着眼于大而全的框架和类库，更要满足希望快速开发打包部署小型应用的自动化需求。这种小型应用多数不需要自己构建source这种阳春白雪的需求，只需要读取全局配置，压缩和部署。简单来说：
   • 减少或者去掉冗余的文件结构
   • 缩减目前的流程复杂度，像grunt，自动帮助开发者构建好层次。以task的形式，帮助开发者实现自动化（spm似乎也正是在朝着这条路上走）。
2. 完善下文档
   完善文档与完善功能相比，开发人员对后者的感冒程度远大于前者，但这却是与使用人员恰好相悖的。spm采用issues的方式记录文档，好处是详细的记录，坏处是一点儿也不系统。所以希望spm的开发人员，或者前人们，能给出一个好的使用文档，或者给出一个最佳实践。

[leoner]

感谢 @StuPig 的反馈， 目前文档在整理中，大部分都在 https://github.com/seajs/spm/wiki中.

对于你提出的问题，这两天会给你做出反馈！

[sunwenchao]

顶楼主~~
在新版spm的使用上我也遇到了和楼主同样的问题，之前也提过issue，但并没有得到一个系统可行的解决方案。

@lifesinger @kangpangpang seajs本身是一个很通用宜用的模块加载器，文档比较细致，很容易上手使用在自己的项目中。而作为其打包必备的配套设施spm，在新版本中却依照自己的标准约定了很多使用的限制，个人认为实属不妥。这对于seajs的推广也是非常不利的。
希望在spm1.0版本发布前，不必着急于完成开发工作。可以考虑下更广泛使用者的需求和真实环境，设计并提供更友好和通用的接口。

[leoner]

谢谢大家的反馈。目前文档工作确实做的不够好，我们也一直在完善。 目前大家可以先到wiki中查找对应的内容。

目前我们对于SPM的定位还是通用灵活可扩展的一个包管理工具，所以在这方面也一直在努力，在这里也希望大家能提出更多的应用场景，其实也不一定非要按照SPM的默认的开发方式，和要求的目录结构， 大家如果觉得自己目前的开发方式和目录结构已经比较成熟，可以简单的描述下，我们可以看看是否有更好的方式来处理。

目前我们对目录的结构已经不做强制要求，只需要提供原文件目录，模块名称等配置即可打包。详情可以看
https://github.com/seajs/spm/wiki/SPM-build-%E5%9F%BA%E4%BA%8E%E5%91%BD%E4%BB%A4%E8%A1%8C%E5%8F%82%E6%95%B0%E6%89%93%E5%8C%85%E8%AF%A6%E8%A7%A3
@StuPig 看下是否能满足。

还有就是从你上面的目录可以看出你的js目录是开发目录，也就是源代码目录，那么处理后的文件，你是需要放在那个目录？

[StuPig]

@kangpangpang SPM build 基于命令行参数打包详解我有看过，但是这个的易用性明显很低哇。这种方式，跟我自己人肉去做命令行压缩和部署区别不大啊。这种方式下，spm的存在的价值就不大了。不知道你怎么认为？

我所期望的方式是基于任务的，压缩、合并、部署，每个都是独立的任务，都可单独执行，更重要的是都可以mixin用户的配置。

[leoner]

@StuPig 是的，目前压缩，合并，部署都是独立的任务，目前每一个任务都需要若干的条件，只要满足，都可以单独执行。

目前命令行参数和用户配置是相互补充的。如果出现相同配置命令行参数优先。

按照你上面的场景目前你最期望的使用方式是如何？我看看现有的SPM如何进行优化啊。

还有就是上面提到的疑问，就是你js目录是源码，那你处理后的文件期望部署到那里？

[StuPig]

@kangpangpang 我希望部署到我指定的一个目录，可以是与该目录平级的一个目录，这个不关键。主要我希望部署后的结构不变，只是每个文件有都变成压缩的了，即相当于复制了一个目录，很简单不是么：）

[leoner]

@StuPig 目前可以这样使用

spm min app --dist=target // 讲app目录中的js进行压缩，并输出到target目录
spm min app/**/*.js -dist=target // 也可以更加详细的指定

具体可以查看 https://github.com/seajs/spm/wiki/Spm-%E5%91%BD%E4%BB%A4%E8%AF%A6%E8%A7%A3

[kaoq123]

也和楼主有相同的看法。之前看了spm给出的打包用例，也看了aralejs的打包，但这些都是针对开发一些通用模块的。对于变动大、通用性小、目录结构相对复杂、需要快速开发的业务，spm的配置实在是繁琐了。所以我其实也是直接把js目录中的所有代码一起放到src中这么做的。
不知道有啥其他好的解决办法没有？期待能看到这一类情况的最佳实践。

[gafish]

虽然升级到了1.6.0版本，但貌似文档依旧不是很完善。