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

Feature Request: Intelligent source root fixing #128

Open
intentionally-left-nil opened this issue Jul 1, 2016 · 2 comments
Open

Feature Request: Intelligent source root fixing #128

intentionally-left-nil opened this issue Jul 1, 2016 · 2 comments

Comments

@intentionally-left-nil
Copy link

intentionally-left-nil commented Jul 1, 2016

My particular scenario is this:

  1. Use browserify to transform src/originalSource.js into temp/libs.js
  2. Use uglify to concat foo.js with temp/libs.js to produce vendor.js
  3. Use sorcery on vendor.js to properly give me source maps that point back to originalSource and foo.js

Basically this is exactly what sorcery is meant for.
Okay, so the issue is that for the browserify-generated file, it generates an inline source map with:

  • sources paths relative to the root of the project (so it would be src/originalSource.js)
  • an empty sourceRoot.

Now, when sorcery tries to pull apart vendor.js, it sees that it is composed of temp/libs.js and foo.js. It then recurses back to temp/libs.js, and then tries to find temp/src/originalSource.js, and of course blows up.

Basically, because the temp/libs.js file is not at the root of the FS, it really should have sourceRoot = '..'

If you're still with me? I'm able to solve this on my own with scripting like this:

    var convert = require('convert-source-map');
    var relative = require('relative');
    var newRoot = relative(file, '.');
    var fileData = fs.readFileSync(file, 'utf8');
    var newSource = convert.fromSource(fileData)
        .setProperty('sourceRoot', newRoot)
        .toComment({multiline: false});

    var newData = convert.removeComments(fileData) + '\n' + newSource;
    fs.writeFileSync(file, newData);

What would be really awesome is if sorcery, inside of each recursive load or loadSync call inside sorcery, it would have fallback logic if it can't find the dependent source files. For example, for my specific case, this pseudocode would fix my issue:

            const sourceRoot = resolve( dirname( this.file ), map.sourceRoot || '' );

            try {
                this.sources = map.sources.map( ( source, i ) => {
                    const node = new Node({
                        file: resolve( sourceRoot, source ),
                        content: sourcesContent[i]
                    });

                    node.loadSync( sourcesContentByPath, sourceMapByPath );
                    return node;
                });
            } catch (e) {
                // The code failed to load the file.
                // Would it succeed if the sourceRoot were changed such that
                // it were relative to the current working directory?
                sourceRoot = relative(this.file, '.');
                this.sources = map.sources.map( ( source, i ) => {
                    const node = new Node({
                        file: resolve( sourceRoot, source ),
                        content: sourcesContent[i]
                    });

                    node.loadSync( sourcesContentByPath, sourceMapByPath );
                    return node;
                });
            }
@intentionally-left-nil
Copy link
Author

I can help write a fix but I bet there are all kind of nasty things with relative paths and especially if there are URL's involved. I'd first like to gauge your interest in taking a "smart sourceRoot detector" functionality to this codebase.

Thanks!

@intentionally-left-nil
Copy link
Author

The ideal fix would be somewhere in browserify (browserify/browserify#1311) but I imagine that there are many cases of other tools that do similar dumb things.

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

No branches or pull requests

1 participant