You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Use browserify to transform src/originalSource.js into temp/libs.js
Use uglify to concat foo.js with temp/libs.js to produce vendor.js
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;
});
}
The text was updated successfully, but these errors were encountered:
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.
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.
My particular scenario is this:
src/originalSource.js
intotemp/libs.js
foo.js
withtemp/libs.js
to producevendor.js
vendor.js
to properly give me source maps that point back tooriginalSource
andfoo.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:
src/originalSource.js
)Now, when sorcery tries to pull apart
vendor.js
, it sees that it is composed oftemp/libs.js
andfoo.js
. It then recurses back totemp/libs.js
, and then tries to findtemp/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 havesourceRoot = '..'
If you're still with me? I'm able to solve this on my own with scripting like this:
What would be really awesome is if sorcery, inside of each recursive
load
orloadSync
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:The text was updated successfully, but these errors were encountered: