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
//@sourceMappingURL is getting replaced with //#sourceMappingURL #3
Comments
Yeah, good idea. Until then with this mold-source-map transform you could switch this out today if you wanted. |
Yeah agreed. Maybe just let it stay as-is for now and people running nightlies or whatever can use that transform, then in 12 weeks or so when those changesets hit stable you can flip the switch and convert everything from |
Chrome is removing the deprecation warning for at least a while. https://code.google.com/p/chromium/issues/detail?id=256636 |
so any more info on when it would be reasonable to switch to the updated api? |
Chrome 29 I believe, which should be 12 weeks after Chrome 27 which was released on 2013-06-18. Still some time away. |
Chrome 30 is now stable as of October 3; it's probably time to switch. |
How is it looking for other browsers that support source maps? Did Firefox make the change. It's nice to have this, but also not urgent IMHO. I looked into chrome's source a bit and they support both versions right now and I don't see that they'll take that out any time soon. However if the risk of breaking anything does no longer apply at all, we should move to the new version. An option that I see is that |
Here is the actual status of new SourceMapSyntax support: I think it's time to get implemented. |
@Anachron thanks and agreed. Now we just need to make sure we do this properly without breaking transpilers that generate sourcemaps in the old style and/or dependent modules. Changes will actually have to occur in other modules, i.e. we'll generate a Also the inline-source-map module has to change here There are lots of modules that will have to get upgraded. I'm starting to compile a list of modules we should PR on after the changes are made and hope to get some of your help on this. Also please make me aware of modules that may break due to these changes so we can at least let the authors know about this. |
Modules that need to upgrade deps via PRsI listed them as checkboxes in the hopes that I get some help in making these PRs. Please pick any one, upgrade the dependency, PR and ensure it gets merged. Dependents of convert-source-map
Dependents of inline-source-mapIf I missed any please let me know. |
@thlorenz Oh, but I even pointed out what should be different in those modules to keep the compatibility :) Anyway, I will check if I can do some PRs, I never did any before, tbh. |
@Anachron don't worry about it - at least until I actually upgraded |
@thlorenz When will you submit these upgrades? Will you create a new version (tag), create a branch or keep changes pending? |
I'm planning to update |
Hey @thlorenz, how is it going? |
The following changes have been made to conform to new source map specs:
As a result, these modules consume This will keep most dependent modules working, except the ones that try to consume the produced sourcemaps from either of these modules. These dependents need to fix the incompatibility when they upgrade to The next step is to update browser-pack to use these latest versions in order to make browserify sourcemaps conform to the new spec. I checked through the above mentioned modules and it seems that none of them will have compatibility problems except typefy which needs to change this line. |
//@sourceURL
; I believe//@sourceMappingURL
will be following: http://code.google.com/p/v8/source/detail?r=14883//@sourceMappingURL
: https://hg.mozilla.org/mozilla-central/rev/c85bb7761528Didn't want to file this with all your source mapping related repos, and it's probably too early to make the switch, but thought it'd be worth tracking.
The text was updated successfully, but these errors were encountered: