> * IMO, it is impractical to just take every foo/bar.js and see if there
> is a foo/bar.map because the extra http request overhead (think when
> there are dozens/hundreds or scripts on a page), possibly slowing down
> the displaying of sources in debuggers depending on implementation,
> questions as to what to do when there is both a @sourceMappingURL and a
> foo/bar.map, etc
Although this would only be needed if the user opened the debugger and took an action that might require a sourcemap, such as setting a breakpoint. That makes it relatively rare and it wouldn't impact the typical site visitor.
> * The possibility exists of adding a new @hasImplicitSourceMap style
> comment directive that would basically say that if the current script is
> foo/bar.js then there should be a source map located at foo/bar.map,
> which would make the whole renaming both the generated js and the source
> map scenario easier to deal with. I'm wary of adding these @ directives
> because once you do they tend to never go away and they have the
> potential to add a bunch of cruft that debugger authors will have to
> deal with. That said, if this is the best solution, then I'm all for it.
A simple "assume the defaults" works for me. The important thing is that I want to preserve the simplicity of renaming files for web devs. We've already seen this happen, when we provided jquery-2.0.0.min.js and the corresponding map/uncompressed to the Google CDN they renamed it to jquery.min.js breaking the link between the files. So it's not a theoretical concern.