Errors on byte order mark ASCII code 65279

[tysonmatanich]

On line 87 of map-generator.coffee, prev can contain a byte order mark (ASCII code 65279) which causes JSON.parse(prev) to fail.

Updating to the following, which trims the string, fixes the issue:
JSON.parse(prev.substring(prev.indexOf("{"), prev.lastIndexOf("}") + 1))

[SLaks]

It would be better to explicitly check for & remove a BOM, and continue to fail on other invalid JSON.

https://www.npmjs.org/package/strip-bom

[ai]

Hm. It is difficult question. If BOM is valid in JSON, you should create issue in JSON ;). If BOM is invaliad you should create issue in you prev map builder tool.

How you generates map with BOM?

[SLaks]

No.

BOMs are an artifact of the UTF8 encoding.
They should appear in files that contain UTF8 bytes, but should be removed when decoding those bytes to a string.
nodejs/node-v0.x-archive#1918

[tysonmatanich]

I am using Autoprefixer which reads the source map in from a file that can begin with BOM.

[ai]

@tysonmatanich why your map contains BOM? What tool you use before Autoprefixer, which add BOM to map?

[tysonmatanich]

Sass via Visual Studio Web Essentials. Might be a Windows thing.

[ai]

Good time to buy Mac :D

[ai]

@tysonmatanich without humor I recommend to create issue in Visual Studio Web Essentials. Of cource, we can fix it in PostCSS. But Web Essentials will still generate wrong maps and we will fix and fix all processors one by one.

PostCSS fix will not fix the issue because other processors will fall too on this wrong map.

[tysonmatanich]

@SLaks do you know if it's Web Essentials or node-sass is adding the BOM?

[am11]

@tysonmatanich, regardless of what node-sass does to map file, its definitely WebEssentials issue. WE does post-processing (especially to fix this libsass issue: sass/libsass#242) and write it back to map file.

I think this is the issue with Sytem.Web.Helpers.Json, which need to be reported at ASP codeplex repo.

I have recently replaced all the occurrences of Sytem.Web.Helpers.Json with JSON.NET. You can try pulling the changes and do the same in your code. Hopefully that fixes the issue. Otherwise, we would need to do something like this to avoid the BOM (which I highly doubt would be required after the JSON.NET change).

[SLaks]

None of that is true; under ordinary circumstances, BOMs never appear in strings.

The BOM is added when writing the strong back to bytes (on disk, when we save the modified JSON to a file)

[am11]

None of it? Well this is a WE's issue! ;)

@tysonmatanich, just ignore the rest of my previous comment. This issue is fixed by am11/WebEssentials2013@3a86bb7 via madskristensen/WebEssentials2013#1096. No more BOM..

[tysonmatanich]

Thanks, I will give it a try.