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

x-sourcemap - header (Sourcemap-URLs) doesn't respect ROOT_URL / ROOT_URL_PATH_PREFIX (fix / hack included) #2627

DanielDornhardt opened this issue Sep 18, 2014 · 7 comments


Copy link


I'm working on a client project and one requirement was for the meteor project to be able to run in a "subdirectory" on the server like this:

It works fine for most things, but one thing I noticed with Meteor itself was that I got errors about all the sourcemap - files not being found.

After some reading and checking I found that the source map URLs are sent via an HTTP-Header "X-SourceMap" in the webapp - Package in webapp_server.js (at the time of writing in Line 391).

  // Set the X-SourceMap header, which current Chrome, FireFox, and Safari
  // understand.  (The SourceMap header is slightly more spec-correct but FF
  // doesn't understand it.)
  // You may also need to enable source maps in Chrome: open dev tools, click
  // the gear in the bottom right corner, and select "enable source maps".
  if (info.sourceMapUrl)
    res.setHeader('X-SourceMap', info.sourceMapUrl);

I could fix this for my project by simply adding meteor_runtime_config.ROOT_URL_PATH_PREFIX to the source map URL:

    res.setHeader('X-SourceMap', info.sourceMapUrl);
    res.setHeader('X-SourceMap', __meteor_runtime_config__.ROOT_URL_PATH_PREFIX + info.sourceMapUrl);

That does the trick for me (for now). As I don't grok the entire stack it's possible that this should be handled differently, but it'd be nice if meteor would take care to allow for the use of multiple meteor apps on a single domain (or is it possible that I overlooked a different route to do the same thing?)

I also already patched IronRouter and CollectionFS to support subdirectories as well, and everything seems to still be working from my point of view. The Patches aren't merged into the main Repositories of those projects yet, but I hope they will be sooner or later. You can see the changes on my github.

I think I could also make a blog post with some explanations on how to set up meteor behind a reverse proxy to be served from a subdirectory and which details to have an eye on for it to work.

The only thing I still not trust entirely is the "spiderable" - package, as it's doing multiple layers of requests by design, and I'm still not sure it delivers the right responses all the time, especially when Facebook and what-have-you try to access static files with the escape_fragment header set at the same time.

But that's an issue for another day and I'm still hoping for server sided Blaze - Rendering to save my neck there! ;)

Ok, long text, thanks for reading and best wishes, have a nice day and I'd love to get some feedback on if it's a good idea to mess with the x-sourcemap - header, and to run meteor in a subdirectory in general.

Best wishes


@DanielDornhardt DanielDornhardt changed the title x-sourcemap - header (Sourcemap-URLs) don't respect ROOT_URL / ROOT_URL_PATH_PREFIX (fix / hack included) x-sourcemap - header (Sourcemap-URLs) doesn't respect ROOT_URL / ROOT_URL_PATH_PREFIX (fix / hack included) Sep 18, 2014
Copy link

Looks like a bug! I'll look into it.

Copy link

meule commented Sep 28, 2014

Daniel, I have the same problem — requirement for the meteor project to be able to run in a "subdirectory". But I have less skills than you. So could you help me a little bit?
How to apply your changes to Iron Route package?
When I just edit the package files in my ~/.meteor folder, I get an error during 'meteor build' command.

Copy link
Contributor Author

Hello Meule,

in my experience it's best to either still use meteorite to use your own fork of a repo, or, what seems to work as well:

You can copy / clone any package to your local packages/ directory within meteor. As long as the package name (in the Package.descripe - call in the packages.js - file) matches, meteor will this version instead of the one downloaded via the meteor package manager. This even works for meteor core packages, which is nice for testing, monkeypatching and debugging :) .

So just clone IronRouter to your packages-directory and do the changes there.

However, I don't have any experience yet with using "meteor build" in this context or for running meteor projects in a subdirectory. We still run our beta via meteor via mrt run / meteor run if you're not using meteorite. Using the --production parameter meteor does the same optimizations as for the build, I think.

So, are your really at a stage in the project where you need to be using 'meteor build'?

Also, a last point: If all that doesn't help, it might be helpful to provide more detailed error messages as they appear when running "meteor build".

Best wishes


dgreensp added a commit that referenced this issue Sep 29, 2014
When you set ROOT_URL_PATH_PREFIX, source maps are not found because the server serves them at a different path from where the client looks for them.

I don’t understand this code super well, but based on what’s reported in issue #2627, the new code seems strictly more correct than the old code.
Copy link

Fixed on the devel and release-0.9.4 branches.

Copy link
Contributor Author

Thanks @dgreensp , that's great!

@meule : just quickly, because I had to reorganize my packages again today as well: Because I wasn't sure which iron-router - package Meteor was using, I "downgraded" it manually by

a) cloning my repo with the patch from inside my packages dir:

git clone

and then from inside the dir, change to the 'supportSubdirectoriesOnDomain' branch:

git checkout supportSubdirectoriesOnDomain

and then finally I gave it a name in Package.describe() in the package.js - file which wasn't iron:router - i named it daniel:iron-router (actually differently, but this is an example, use what would be alright for you).

Then i said

meteor remove iron:router

and then

meteor add daniel:iron-router

to make sure that my specific code is used.

Pretty unnice for now, and my package isn't current anymore, I might need to update it sometime in the future, but for now it works.

I hope that sooner or later iron:router will pick up these or similar changes.

Best wishes


Copy link

meule commented Sep 30, 2014

Daniel thank you so much!

I use last meteor 0.9.3
I 'git clone' your branch (supportSubdirectoriesOnDomain) to my ~/.meteor/packages folder as d:iron-router.
But in package.js file from your rep there is no name property in Package.describe():
Package.describe({ summary: 'Routing specifically designed for Meteor', version: '0.9.1', });
And structure of every folder in packages is different than in yours: there is folder named with package version, and inside it there are folders os, npm and web.browser instead of lib and test in yours.

So when I just meteor remove iron:router and add d:iron-router, I got an error: d:iron-router: no such package :-(

Copy link
Contributor Author

Hi Meule,

you can name the package in packages however you want, but i'd recommend iron-router, as that's what the repo is called i think. Colons ( : ) are still strange in paths i feel.

2nd: Did you checkout the branch 'supportSubdirectoriesOnDomain'? Are you on the correct branch?

This is what my package directory looks like after adding it to meteor:


Then add the name: 'my:iron-router' to the Package.describe() - object as a new key. After that you should be able to

meteor add my:iron-router


One last thing: Maybe we should take this thread somewhere else, because it's only tangentially related to the ticket? You can write me at daniel at dornhardt dot com or find me on Twitter by searching for Daniel Dornhardt I recon.

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

No branches or pull requests

3 participants