support for associating source-maps with assets in barback

[DartBot]

<img src="https://avatars.githubusercontent.com/u/2049220?v=3" align="left" width="96" height="96"hspace="10"> Issue by sigmundch
Originally opened as dart-lang/sdk#12339

---

See comments in this CL:
https://codereview.chromium.org/22396004/diff2/3001:23001/pkg/observe/lib/transform.dart?column_width=80

Source-maps need to point to the asset before it was transformed, but barback doesn't necessarily expose intermediate assets.

I'm openinig this bug to brainstorm and track progress on this.

Some ideas:
 - source-map composition (see issue dart-lang/source_maps#5)
 - exposing in pub-serve intermediate assets using a special URL (for instance, path?version=x)

[DartBot]

<img src="https://avatars.githubusercontent.com/u/188?v=3" align="left" width="48" height="48"hspace="10"> Comment by nex3

---

I think we'll ultimately want some sort of special URL for accessing intermediate (or at least source) versions of files. As long as we support in-place transforms, there's not going to be a natural URL for retrieving the source file. For example, if you run the observable transform on "package:myapp/myapp.dart" and it produces a post-transform "package:myapp/myapp.dart", accessing "/packages/myapp/myapp.dart" will always have to return the post-transformation version.

Explicitly naming versions is tricky, because that can change from run to run if the configuration of transformers changes. We could just expose a black box URL, but that still screws with caching. Maybe the best option is to only support special access to the on-disk sources (since that's what users are editing anyway) via something like "/_sources/packages/myapp/myapp.dart", then use sourcemap composition to generate the correct sourcemaps for pipelined transformations.

---

cc @munificent.

[DartBot]

<img src="https://avatars.githubusercontent.com/u/2049220?v=3" align="left" width="48" height="48"hspace="10"> Comment by sigmundch

---

Marked this as blocking dart-archive/observe#29.

[DartBot]

<img src="https://avatars.githubusercontent.com/u/2049220?v=3" align="left" width="48" height="48"hspace="10"> Comment by sigmundch

---

What are your thoughts on an API to support source-maps. Maybe we can add the API and later do the implementation details?

One idea from John: like 'addOutput' also have 'addSourceMap' so that barback has all the details it needs to recognize that the sourcemap is associated with a particular input?

---

cc @jmesserly.

[DartBot]

<img src="https://avatars.githubusercontent.com/u/188?v=3" align="left" width="48" height="48"hspace="10"> Comment by nex3

---

I don't think we want to commit to an API before we have a comprehensive plan for source maps. I don't think it would provide much benefit anyway.

[DartBot]

<img src="https://avatars.githubusercontent.com/u/188?v=3" align="left" width="48" height="48"hspace="10"> Comment by nex3

---

Set owner to @nex3.
Added Started label.

[DartBot]

<img src="https://avatars.githubusercontent.com/u/1081711?v=3" align="left" width="48" height="48"hspace="10"> Comment by jmesserly

---

fyi -- I made a change recently to Polymer, that made source maps less important for us. We now generate code that preserves line numbers. (Your @­observable fields just become a long line w/ getter+setter+field)

[DartBot]

<img src="https://avatars.githubusercontent.com/u/188?v=3" align="left" width="48" height="48"hspace="10"> Comment by nex3

---

Added Accepted label.

[DartBot]

<img src="https://avatars.githubusercontent.com/u/3276024?v=3" align="left" width="48" height="48"hspace="10"> Comment by anders-sandholm

---

Removed Library-Barback label.
Added Pkg-Barback label.