Skip to content

Make relative applied source paths relative to CWD #41

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

Closed
wants to merge 1 commit into from
Closed

Make relative applied source paths relative to CWD #41

wants to merge 1 commit into from

Conversation

lydell
Copy link

@lydell lydell commented Jun 2, 2014

When generating a source map, the paths put into the sources array of
the source map normally come from pos.source properties on the AST
nodes. These are today assumed to be relative to the current working
directory, since that’s how any original source maps are resolved and
applied.

Paths in the sources array can also come from applied original maps.
Relative such source paths are relative to the original source map --
not to the current working directory!

It does not make sense to mix paths that are relative to different
things. Therefore this commit makes sure that applied relative source
maps are rewritten to be relative to the current working directory, like
all other sources.

An existing test was updated to test this.

When generating a source map, the paths put into the `sources` array of
the source map normally come from `pos.source` properties on the AST
nodes. These are today assumed to be relative to the current working
directory, since that’s how any original source maps are resolved and
applied.

Paths in the `sources` array can also come from applied original maps.
Relative such source paths are relative to the original source map --
not to the current working directory!

It does not make sense to mix paths that are relative to different
things. Therefore this commit makes sure that applied relative source
maps are rewritten to be relative to the current working directory, like
all other sources.

An existing test was updated to test this.
*/

function dirname(url) {
return url.replace(/\/?[^/]+$/, '') || '.';
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there any reason not to use regular path operations and then normalize to URLs when setting the source name? I think all that is needed is just replacing \ with / to convert to URL, and that is only needed on Windows.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To clarify, I mean treating the source property of the AST as a file path and then converting that (and any paths derived from that) to URLs only when adding the path to the source map. This would allow using the regular Node path module functions.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

.applySourceMap() requires a URL as its third argument; a Windows-style path does not work. originalMap.sourcesRelativeTo is guaranteed to be a URL, regardless of operating system. Using path.dirname() on it would change it to a Windows-style path when on Windows. Which would require us to change it back to a URL (source maps should contain URLs since they are used in the browser). So I simply chose between two different regexes :)

But you are right: We should probably use standard path operations, and normalize all paths added to the source map to URLs—also in exports.emit. I’d recommend urix.

@necolas
Copy link
Contributor

necolas commented Jun 4, 2014

Please can you apply this against reworkcss/css (the new home for parse/stringify development)

@necolas necolas closed this Jun 4, 2014
@lydell
Copy link
Author

lydell commented Jun 4, 2014

reworkcss/css#28

@lydell lydell deleted the fix-applied-source-paths branch June 4, 2014 19:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants