Skip to content
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

support for associating source-maps with assets in barback #12339

Closed
sigmundch opened this issue Aug 9, 2013 · 9 comments
Closed

support for associating source-maps with assets in barback #12339

sigmundch opened this issue Aug 9, 2013 · 9 comments
Assignees
Labels

Comments

@sigmundch
Copy link
Member

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 #11783)
 - exposing in pub-serve intermediate assets using a special URL (for instance, path?version=x)

@nex3
Copy link
Member

nex3 commented Aug 9, 2013

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.

@sigmundch
Copy link
Member Author

Marked this as blocking #12340.

@sigmundch
Copy link
Member Author

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.

@nex3
Copy link
Member

nex3 commented Aug 9, 2013

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.

@nex3
Copy link
Member

nex3 commented Oct 2, 2013

Set owner to @nex3.
Added Started label.

@jmesserly
Copy link

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)

@nex3
Copy link
Member

nex3 commented Jan 14, 2014

Added Accepted label.

@anders-sandholm
Copy link
Contributor

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

@DartBot
Copy link

DartBot commented Jun 5, 2015

This issue has been moved to dart-archive/barback#6.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

6 participants