Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
x-sourcemap - header (Sourcemap-URLs) doesn't respect ROOT_URL / ROOT_URL_PATH_PREFIX (fix / hack included) #2627
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:
From: res.setHeader('X-SourceMap', info.sourceMapUrl); To: 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.
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?
in my experience it's best to either still use meteorite https://github.com/oortcloud/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".
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 firstname.lastname@example.org:DanielDornhardt/iron-router.git
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
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.
Daniel thank you so much!
I use last meteor 0.9.3
So when I just
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
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.