-
-
Notifications
You must be signed in to change notification settings - Fork 57
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tests fail due to charset issue #36
Comments
As you can see all tests are passing on travis, so I the covered features work. The example you posted is not supposed to work .. charsets are not conserved during conversion. However I agree with you that Thanks. |
I have just bumped into the same problem trying to package the latest convert-source-map for Debian. The test can be made to fail on Travis by bumping the inline-source-map dependency up to 0.6.1: It will take me a little while to workout what the simple change should be in index.js though :-) |
Sorry can't help you much, but I'd love a PR that shows the problem via a test and then fixes it :) |
Fixed with #51 |
@thlorenz sadly.. having charset in inline source map is broken in webpack source map loader.. not sure if you view it as their issue, but just so you know this latest change breaks usage of babel with webpack among other things probably. |
Sorry to hear that @scamden. However is there anything we can do here to help? It'd be pretty drastic, but we could fix webpack by unpublishing the minor upgrade from npm and republishing this as a major upgrade (even though I think we shouldn't need to since there weren't any API changes). |
That's super cool of you! There actually is a PR to fix the issue over there, but it hasn't seen much activity for a while, due partially to the contributor failing to sign the CLA so far. I'm hoping it might get more attention now that such a major tool breaks with them. The pr is here: webpack-contrib/source-map-loader#21 (comment) Thanks again for a rad response to something that's not even your issue :) |
Ah nice looks like the fix is under way and simple enough ... don't think we need to do anything here then. Good luck! |
I'm running the self-tests as part of an effort to get this module packaged as an RPM for Fedora, but three tests are failing due to charset issues.
From a very brief analysis, it seems that the fromComment() function is ignoring the character set on the comment, and that the toComment() function isn't adding the charset back in.
Here's a very simple program to explain:
The output is as follows:
As you can see, the initial comment contains the string "charset=utf-8", but after the conversion the charset is missing from the resulting comment.
The text was updated successfully, but these errors were encountered: