meteor-socialize-demo
meteor-socialize-demo copied to clipboard
Version conflict prevents demo startup
Hi @copleykj, I wanted to try out your demo of the socialize package, but it doesn't seem to work anymore. If you try to start it, it throws these version conflicts:
=> Errors prevented startup:
While selecting package versions:
error: Potentially incompatible change required to top-level dependency: socialize:user-blocking 1.0.1, was 1.0.2.
Constraints on package "socialize:user-blocking":
* socialize:[email protected] <- socialize:friendships 1.0.2
* socialize:[email protected] <- socialize:feed 1.0.2
* socialize:[email protected] <- socialize:likeable 1.0.2
* socialize:[email protected] <- socialize:user-profile 1.0.2
To allow potentially incompatible changes to top-level dependencies, you must pass --allow-incompatible-update on the command line.
=> Your application has errors. Waiting for file change.
I was able to workaround this by removing socialize:user-blocking from the top-level dependencies in meteor/packages. But there is another issue:
app/client/main.scss: warn: There are some @import rules those are not taking effect as they are required to be in the beginning of the file.
So it seems the scss is invalid.
The scss warning has been output for quite some time. I'm not sure which version introduced it but I don't believe scss requires import rules at the top, and doing so would not produce the desired css.
Yes, .scss imports have to be at the top. But you can work-around this by re-structuring the SCSS files.
According to the sass docs @import can be placed just about anywhere with the exception of within mixins or control structures.
When Sass imports a file, that file is evaluated as though its contents appeared directly in place of the @import. Any mixins, functions, and variables from the imported file are made available, and all its CSS is included at the exact point where the @import was written. What’s more, any mixins, functions, or variables that were defined before the @import (including from other @imports) are available in the imported stylesheet.
I guess this is one of the differences of Node SASS compared to libSass