在spm doc watch 模式下，通过ajax加载json返回数据中都自动拼上了define(....)导致无法正常解析json数据的问题

[forestlioooooo]

如题，如何破？，我使用的是spm3.x
目前我的解决方法是在把xxx.json 修改成xxx.jsonx处理，但是应该还有正经的解决途径才对
建议：是否可以对examples/目录下的内容不进行wrap处理

[sorrycc]

试试 xxx.json?nowrap ?

[afc163]

是不是可以加个 XMLHttpRequest 的判断？

[forestlioooooo]

@sorrycc ，在代码里面加入无业务含义的内容，这样不好吧....

[popomore]

确实，尝试下 content-type 判断

[sorrycc]

header 判断 xhr 请求特殊处理是可以解决，不过通过加配置来解决会不会更通用? 之前也有遇到其他场景需要手动加 nowrap 参数的。

{
  "spm": {
    "serveArgs": "--nowrap *.json"
  }
}

[afc163]

感觉配置太多了，容易让人费解。

不知道 XHR 请求有需要包裹的场景没。

[sorrycc]

暂时想不到 xhr 时需要包裹的场景。。

[forestlioooooo]

以下内容已脱离问题本身，说的是处理该种情况的方案：

非正式代码是肯定不需要包裹的，如果包裹了反而不好。
比如在 examples/ 目录下面我个人存放了一个处理兼容性的js文件
例如：检查客户端是否支持Function的bind函数，如果支持就不管，如果不支持就加入该支持。
在这种场景之下是肯定不会包裹的，而且不会作为控件的依赖库放到正式代码里面（bind函数的支持已经非常普遍，只是对个别客户端做兼容检测，正式代码假定所有的客户端都是支持的，至于为什么这么假定是另外一个话题，这里不谈）。

另外一个我个人认为比较重要的地方是：目前serve下没有一个能够划分场景的模式：
两个场景：1、serve本身的运行和空间；2、开发者嵌入到server内的运行空间
这两种场景并没有明确的划分，以至于需要在package.json中加入spm.serveArgs来进行处理，这种方式我个人认为是一种折衷的方案

既然提出来了问题，就带个方案抛砖引玉：通过目录的方式划分场景，例如我上面说到的以examples/目录为用户空间，里面允许放入个性化内容，和外面的环境互相不影响

[afc163]

那就默认去掉对 XHR 的包裹吧，先解决 90% 的问题。

[forestlioooooo]

不知道为什么你们没遇到需要加载json的情况，我说一说我这里的情况吧：
我现在在开发一个web聊天控件，因为比较复杂，所以我使用spm来管理代码，然后，我在examples目录下面放了一个index.html 作为 demo演示的页面，当然既然演示肯定就不能没数据，所以造了一些个模拟数据放到了该目录下，打开这个页面的时候，就把这些模拟数据填充到控件中去，以便于能比较直观的了解该控件实现了哪些功能

[afc163]

因为 JSON 文件也是标准的 CommonJS，是可以 require 的。

所以如果在演示中（限于 md 文件中的代码块）这么用：

var data = require('./data.json');
// use data

其实是可以跑通的，我们在很多情况下也是这么实践的。

当然楼主用的是自己的 html 文件，所以应该是用比如 $.ajax 去调用了，这种情况下如果包裹了 define ，就会报错了。

$.get('./data.json')

针对 XHR 的文件请求，的确不应该包裹 define 。

[forestlioooooo]

{
  "spm": {
    "serveArgs": "--nowrap *.json"
  }
}

我暂时可以使用这个方式处理，但是没有场景划分，没有用户的私有空间，以后可能还会遇到类似问题

[afc163]

根本没有这个配置。。。上面只是在讨论。

[forestlioooooo]

汗，既然还没确定方案，我还是墙裂要求划分用户私有空间出来；以后各在各的小屋干活，互不干扰，^_^

[afc163]

这里我们也有同样的问题：aralejs/autocomplete@c2c960c

我建议楼主先临时加上 nowrap 的配置，后续 serve-spm 升级了再看。

[forestlioooooo]

原来你们一直这么干啊，好吧，那就等下个版本