-
Notifications
You must be signed in to change notification settings - Fork 135
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
Sass.js is a singleton #43
Comments
Are you using the Synchronous API (sass.sync.js, also the API used when run in Node) or the Worker API?
That sounds like you'd like to be able to pass data from
Not without losing SourceMaps accuracy… |
@rodneyrehm both, actually, this is for the SystemJS/JSPM Sass plugin. It uses the synchronous api for the builder and worker for the loader. |
But it's only the synchronous API that's failing for you, right? I'm asking because the following is working fine for me: <script src="dist/sass.js"></script>
<script>
var alpha = new Sass();
alpha.importer(function(request, done) {
done({
content: '.alpha { content: "alpha"; }',
})
});
alpha.compile('@import "testfile";', function(result) {
console.log("alpha", result.text);
});
var bravo = new Sass();
bravo.importer(function(request, done) {
done({
content: '.bravo { content: "bravo"; }',
})
});
bravo.compile('@import "testfile";', function(result) {
console.log("bravo", result.text);
});
alpha.compile('@import "testfile";', function(result) {
console.log("alpha", result.text);
});
bravo.compile('@import "testfile";', function(result) {
console.log("bravo", result.text);
});
</script> Is the ability to pass options to the importer callback something you could work with, or does that not solve your problem? Do you want to try to implement this and send a PR? |
@rodneyrehm I had to tweak my code a little bit, but yes, the webworker api spins up a new worker for each. Thanks for your example! I tried to pass in the option like you outlined above, however, I appear to get the same results as before. Taking a look at the code, it looks like the options are assigned to the global Sass._options temporarily and then they're set back. However, from what I can tell, the calls to the importer are happening asynchronously, so eventually we get in a state where only the last options passed in are honored. Maybe if there was a way to pass the options on without hanging them off Sass._options. |
please try the importer-options branch. According to the passing test, the options are passed in correctly. |
Thanks @rodneyrehm! You're awesome! I'll take a look and see how it works. |
@rodneyrehm that appears to work perfectly. Thank you! Being able to pass importer options into compile is exactly what I need. I'm now running into some issues with regard to emscripten modules and the way they're imported with SystemJS. You might take a look at the SystemJS builder issue and see if you can offer any insight. Thanks again! |
(Whoops accidentally closed the issue.) |
released in 0.9.6 |
I'm running into an issue where I need a separate instance of sass.js per compile, but it appears that sassjs is a singleton.
My use case is that for each file I compile, I cache its directory as a base url and in my custom importer I use that base url to determine the relative path. I'm enclosing that base url in a closure, but anytime I set importer it overrides the previous importer (because sassjs is a singleton) and I'm stuck with the last base url that was set.
Any ideas on how I can get around this? Thanks!
The text was updated successfully, but these errors were encountered: