changcheng / wro4j

Automatically exported from code.google.com/p/wro4j
0 stars 0 forks source link

@Import of scss not possible #487

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
When I use cssImport Prepocessor and I want to use @import within a SCSS 
(Sass-File) I get a

WARN CssImportPreProcessor? - Invalid import detected: global.scss

When I save my Sass-Stuff in a .css File and @import that File everything works 
fine.

What is the expected output? What do you see instead?
- The Preprocessor should also import .scss Files
- Not only .css Files

What version of the product are you using? On what operating system?
I'm using wro4j-maven-plugin 1.4.7 on a Windows 7 Machine

Please provide any additional information below.
Some more Information in the Comment-Section here:
http://code.google.com/p/wro4j/wiki/SassCssSupport

Original issue reported on code.google.com by fwebdev on 11 Jul 2012 at 3:03

GoogleCodeExporter commented 9 years ago

Original comment by alex.obj...@gmail.com on 11 Jul 2012 at 3:04

GoogleCodeExporter commented 9 years ago
Cannot reproduce the problem. The .scss file is imported properly with 
CssImportPreProcessor. You can check-out the example here: 
https://github.com/alexo/wro4j/tree/issue487  (in wro4j-examples/wro4j-demo 
project).

Need more details about how to reproduce reported issue.

Original comment by alex.obj...@gmail.com on 12 Jul 2012 at 2:59

GoogleCodeExporter commented 9 years ago

Original comment by alex.obj...@gmail.com on 12 Jul 2012 at 3:10

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
Alex,

I've reproduced this issue and I believe I have an explanation as to the 
trigger. It comes down to how the imports are resolved. The 
CssImportPreProcessor should not be used as the import mechanism of SASS files. 
SASS' import behavior is distinct from CSS.

I'm using the Maven build with a custom wro.properties file. If you have two 
simple SASS files:

In a /sass/ folder we have test.scss and _red-span.scss. The contents of 
test.scss are:
@import "red-span";
  div {
    color: blue;
  }

Notice that red-span is a partial so SASS wont compile it to CSS and no 
underscore is required in the reference to it 
(http://sass-lang.com/docs/yardoc/file.SASS_REFERENCE.html#partials).

The contents of _red-span.scss are:
  span {
    color: red;
  }

So the expected output would be something like:
  span {
    color: red;
  }

  div {
    color: blue;
  }

If my wro.properties looks like this:
preProcessors=cssImport,rubySassCss
postProcessors=cssMinJawr
uriLocators=servletContext,classpath,url

then CssImportPreProcessor fails as invalid.

If instead I put rubySassCSS first:

preProcessors=rubySassCss,cssImport
postProcessors=cssMinJawr
uriLocators=servletContext,classpath,url

then SASS throws a syntax error because it can't find the file.

The final piece of the puzzle is that with the second wro.properties, if I 
reference the file using a path from the basedir, it works.  Is this enough to 
go on?

Original comment by sashasklar on 18 Jul 2012 at 4:07

GoogleCodeExporter commented 9 years ago
The partial support for sass should be handled by a dedicated processor which 
shouldn't be very hard to implement. It would be nice if somebody would 
contribute for this issue. From my point of view, it has low priority, since 
you can easily update import statement with a correct url value (same way you 
would do with css)

Original comment by alex.obj...@gmail.com on 8 Aug 2012 at 8:17

GoogleCodeExporter commented 9 years ago

Original comment by alex.obj...@gmail.com on 17 Dec 2012 at 8:11

GoogleCodeExporter commented 9 years ago

Original comment by alex.obj...@gmail.com on 17 Dec 2012 at 8:11

GoogleCodeExporter commented 9 years ago

Original comment by alex.obj...@gmail.com on 9 Jan 2013 at 6:28

GoogleCodeExporter commented 9 years ago

Original comment by alex.obj...@gmail.com on 9 Mar 2013 at 11:17

GoogleCodeExporter commented 9 years ago

Original comment by alex.obj...@gmail.com on 12 May 2013 at 5:26

GoogleCodeExporter commented 9 years ago

Original comment by alex.obj...@gmail.com on 8 Jun 2013 at 9:50

GoogleCodeExporter commented 9 years ago

Original comment by alex.obj...@gmail.com on 13 Sep 2013 at 3:54

GoogleCodeExporter commented 9 years ago
I managed to provide the jruby runtime with the current working directory (the 
location of the sass input file). Then the processor is able to work as 
preprocessor and handles imports correctly. If somebody is interested I can 
provide some code fragments. 

Original comment by dirk.feu...@googlemail.com on 30 Oct 2013 at 8:40

GoogleCodeExporter commented 9 years ago
Sure, please create a pull request or just send a patch (whatever is easier for 
you).

Thanks,
Alex

Original comment by alex.obj...@gmail.com on 30 Oct 2013 at 8:55

GoogleCodeExporter commented 9 years ago
Here is a patch. Note that the 
ro.isdc.wro.extensions.processor.css.RubySassCssProcessor still contains a TODO 
to resolve the path of the sass input file. Currently this only works for 
resources loaded from the servlet context.

Original comment by dirk.feu...@googlemail.com on 30 Oct 2013 at 10:22

GoogleCodeExporter commented 9 years ago

Original comment by dirk.feu...@googlemail.com on 30 Oct 2013 at 10:22

Attachments:

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
Ideally the processor should be agnostic of the resource type being processed 
and its location. I was thinking about an implementation which would "guess" 
the name of the file to import by appending the implicit extension...

Original comment by alex.obj...@gmail.com on 30 Oct 2013 at 10:34

GoogleCodeExporter commented 9 years ago
Since the Ruby Sass compiler needs a real file system working directory (which 
defaults to the "user.dir" property) and uses this directory to resolve 
relative files, providing such a directory is essential when an @import should 
be processed. The RubySassCss processor documentation already has a note about 
this behaviour and proposes to use the processor only as post processor. 

Original comment by dirk.feu...@googlemail.com on 30 Oct 2013 at 2:05

GoogleCodeExporter commented 9 years ago
Though I didn't try it, I think the following approach should work:

- when @import statement is found locate the resourcs being imported.
- if imported resource doesn't exist, try a fallback by appending an extension 
(.scss) and try again.
- if the resource is found, the import is processed properly and should work as 
expected.
- if no resource is found, then the import is really missing. Proceed with 
processing (either ignore or throw an exception).

The only drawback of this approach is that there is potentially one extra 
request for invalid resources for each detected import.

The advantage of this approach is that it still works with virtually any type 
of resource (servletContext, classpath or absolute).

Original comment by alex.obj...@gmail.com on 30 Oct 2013 at 2:25

GoogleCodeExporter commented 9 years ago
Before going into the RubySassCss source code and doing my modifications I also 
tried to work with the default "cssImport" processor and "rubySassCss" as post 
processor. Unfortunatelly the naming magic was not the only issue. I got also 
problems when the "cssUrlRewriting" processor kicks in and tries to replace 
urls containing sass variables which it could obviously not handle correctly. 
And there might be other issues. 

Original comment by dirk.feu...@googlemail.com on 30 Oct 2013 at 2:34

GoogleCodeExporter commented 9 years ago
cssImport and cssUrlRewriting must be pre processors, otherwise the required 
information wouldn't be available. If there are any issues identified during 
implementation of this task, documenting them would really help so that these 
could be addressed later.

I would give it a try with the above algorithm, but I don't really have time 
right now. So, if there is anyone willing to contribute, that would be awesome. 
I can still provide feedback and review contributed code. 

Original comment by alex.obj...@gmail.com on 30 Oct 2013 at 2:51

GoogleCodeExporter commented 9 years ago

Original comment by alex.obj...@gmail.com on 5 Nov 2013 at 1:53

GoogleCodeExporter commented 9 years ago
FYI: While experimenting with Sass I came across another issue with imports 
that the basic cssImport should not be able to handle: In Sass you can use 
imports on files which are not provided by file system but by the ruby runtime 
system (which included a so called gem containing those files). 

Original comment by dirk.feu...@googlemail.com on 12 Nov 2013 at 2:48

GoogleCodeExporter commented 9 years ago

Original comment by alex.obj...@gmail.com on 8 Jan 2014 at 3:10

GoogleCodeExporter commented 9 years ago

Original comment by alex.obj...@gmail.com on 21 Mar 2014 at 9:19

GoogleCodeExporter commented 9 years ago

Original comment by alex.obj...@gmail.com on 8 Apr 2014 at 9:56

GoogleCodeExporter commented 9 years ago
I'm using cssImport,semicolonAppender as preProcessor and 
rubySassCss,cssVariables,cssMinJawr,jsMin as postProcessors. Test sass files 
are twitter bootstrap sass. With bootstrap.sass I add extensions to files 
(.scss) and all files are merged fine (looks like). When postprocessor start 
working I throw exception

2014-05-13 22:22:57 r.i.w.h.WroFilter [DEBUG] Exception occured
ro.isdc.wro.WroRuntimeException: org.jruby.embed.EvalFailedException: 
(SyntaxError) Invalid CSS after "/": expected identifier, was " Core 
variables..."
    at ro.isdc.wro.extensions.processor.support.sass.RubySassEngine.process(RubySassEngine.java:70) ~[wro4j-extensions-1.7.5.jar:1.7.5]
    at ro.isdc.wro.extensions.processor.css.RubySassCssProcessor.process(RubySassCssProcessor.java:59) ~[wro4j-extensions-1.7.5.jar:1.7.5]
    at ro.isdc.wro.model.resource.processor.decorator.ProcessorDecorator.process(ProcessorDecorator.java:89) ~[wro4j-core-1.7.5.jar:1.7.5]
    at ro.isdc.wro.model.resource.processor.decorator.LazyProcessorDecorator.process(LazyProcessorDecorator.java:49) ~[wro4j-core-1.7.5.jar:1.7.5]
    at ro.isdc.wro.model.resource.processor.decorator.ProcessorDecorator.process(ProcessorDecorator.java:89) ~[wro4j-core-1.7.5.jar:1.7.5]
    at ro.isdc.wro.model.resource.processor.decorator.ProcessorDecorator.process(ProcessorDecorator.java:89) ~[wro4j-core-1.7.5.jar:1.7.5]
    at ro.isdc.wro.model.resource.processor.decorator.ProcessorDecorator.process(ProcessorDecorator.java:89) ~[wro4j-core-1.7.5.jar:1.7.5]
    at ro.isdc.wro.model.resource.processor.decorator.ProcessorDecorator.process(ProcessorDecorator.java:89) ~[wro4j-core-1.7.5.jar:1.7.5]
    at ro.isdc.wro.model.resource.processor.decorator.SupportAwareProcessorDecorator.process(SupportAwareProcessorDecorator.java:39) ~[wro4j-core-1.7.5.jar:1.7.5]
    at ro.isdc.wro.model.resource.processor.decorator.ProcessorDecorator.process(ProcessorDecorator.java:89) ~[wro4j-core-1.7.5.jar:1.7.5]
    at ro.isdc.wro.model.resource.processor.decorator.ExceptionHandlingProcessorDecorator.process(ExceptionHandlingProcessorDecorator.java:56) ~[wro4j-core-1.7.5.jar:1.7.5]
    at ro.isdc.wro.model.resource.processor.decorator.ProcessorDecorator.process(ProcessorDecorator.java:89) ~[wro4j-core-1.7.5.jar:1.7.5]
    at ro.isdc.wro.model.resource.processor.decorator.BenchmarkProcessorDecorator.process(BenchmarkProcessorDecorator.java:44) ~[wro4j-core-1.7.5.jar:1.7.5]
    at ro.isdc.wro.model.resource.processor.decorator.ProcessorDecorator.process(ProcessorDecorator.java:89) ~[wro4j-core-1.7.5.jar:1.7.5]
    at ro.isdc.wro.model.resource.processor.decorator.DefaultProcessorDecorator.process(DefaultProcessorDecorator.java:42) ~[wro4j-core-1.7.5.jar:1.7.5]
    at ro.isdc.wro.model.group.processor.GroupsProcessor$1.process(GroupsProcessor.java:131) ~[wro4j-core-1.7.5.jar:1.7.5]
    at ro.isdc.wro.model.group.processor.GroupsProcessor.applyPostProcessors(GroupsProcessor.java:115) ~[wro4j-core-1.7.5.jar:1.7.5]
    at ro.isdc.wro.model.group.processor.GroupsProcessor.process(GroupsProcessor.java:84) ~[wro4j-core-1.7.5.jar:1.7.5]
    at ro.isdc.wro.cache.support.DefaultSynchronizedCacheStrategyDecorator.loadValue(DefaultSynchronizedCacheStrategyDecorator.java:101) ~[wro4j-core-1.7.5.jar:1.7.5]
    at ro.isdc.wro.cache.support.DefaultSynchronizedCacheStrategyDecorator.loadValue(DefaultSynchronizedCacheStrategyDecorator.java:35) ~[wro4j-core-1.7.5.jar:1.7.5]
    at ro.isdc.wro.cache.support.AbstractSynchronizedCacheStrategyDecorator.get(AbstractSynchronizedCacheStrategyDecorator.java:55) ~[wro4j-core-1.7.5.jar:1.7.5]
    at ro.isdc.wro.manager.ResourceBundleProcessor.serveProcessedBundle(ResourceBundleProcessor.java:63) ~[wro4j-core-1.7.5.jar:1.7.5]
    at ro.isdc.wro.manager.WroManager.process(WroManager.java:159) ~[wro4j-core-1.7.5.jar:1.7.5]
    at ro.isdc.wro.http.WroFilter.processRequest(WroFilter.java:350) ~[wro4j-core-1.7.5.jar:1.7.5]
    at ro.isdc.wro.http.WroFilter.doFilter(WroFilter.java:290) ~[wro4j-core-1.7.5.jar:1.7.5]
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241) [catalina.jar:7.0.52]
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208) [catalina.jar:7.0.52]
    at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:220) [catalina.jar:7.0.52]
    at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:122) [catalina.jar:7.0.52]
    at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:501) [catalina.jar:7.0.52]
    at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:170) [catalina.jar:7.0.52]
    at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98) [catalina.jar:7.0.52]
    at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:950) [catalina.jar:7.0.52]
    at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116) [catalina.jar:7.0.52]
    at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408) [catalina.jar:7.0.52]
    at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1040) [tomcat-coyote.jar:7.0.52]
    at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:607) [tomcat-coyote.jar:7.0.52]
    at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:315) [tomcat-coyote.jar:7.0.52]
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [na:1.7.0_51]
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [na:1.7.0_51]
    at java.lang.Thread.run(Thread.java:744) [na:1.7.0_51]

Anybody has working solution with sass @import?

Original comment by valentin...@gmail.com on 13 May 2014 at 6:30

GoogleCodeExporter commented 9 years ago
There is a pre processor called 'cssImport' which handles @import statements. 
The only limitation it has, is that it doesn't assume the extension of the 
imported resource as sass does. The workaround, until the specialized pre 
processor is implemented, is to add the extension explicitly. Example:
replace @import 'style' with @import 'style.scss'

Original comment by alex.obj...@gmail.com on 13 May 2014 at 9:10

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
Alex, thanks! 

I already done it, so it looks like 
@import "homepage-slider.css.scss";
@import "whos-using-slider.css.scss";

with bootstrap same @import "bootstrap/bootstrap.scss"; 

So is this mean, some error's with ruby. 

Or I could add extended css processor to preProcess sass

Regards,
Valentin

Original comment by valentin...@gmail.com on 14 May 2014 at 11:32

GoogleCodeExporter commented 9 years ago
The cssImport should be added to preprocessor list, rather than to post
processors. Since, it require to know the original resource location. Using
it as a post processor is too late.

Original comment by alex.obj...@gmail.com on 14 May 2014 at 11:40

GoogleCodeExporter commented 9 years ago
No, i mean 
<init-param>
            <param-name>preProcessors</param-name>
            <param-value>cssImport,semicolonAppender</param-value>
  </init-param>
  <init-param>
       <param-name>postProcessors</param-name>
       <param-value>rubySassCss,cssVariables,cssMinJawr,jsMin</param-value>
</init-param>

So, if i right understand cssImport merge all files to one. And rubySassCss 
must do magic on one huge file. Please correct me, if i'm wrong.

Regards,
Valentin

Original comment by valentin...@gmail.com on 14 May 2014 at 11:52

GoogleCodeExporter commented 9 years ago
That is correct. After cssImport is applied, the resulted content will have
all imported resources merged.

Original comment by alex.obj...@gmail.com on 14 May 2014 at 12:06

GoogleCodeExporter commented 9 years ago
But could it be that that commented "input[type=\"search\"]" special chars give 
and error like?

2014-05-14 15:38:58 r.i.w.h.WroFilter [DEBUG] Exception occured
ro.isdc.wro.WroRuntimeException: org.jruby.embed.EvalFailedException: 
(SyntaxError) Invalid CSS after "/": expected identifier, was " Core 
variables..."

Original comment by valentin...@gmail.com on 14 May 2014 at 12:13

GoogleCodeExporter commented 9 years ago
It could be. The SassProcessor uses ruby to process the sass resources. If
ruby implementation has such limitation, the processing fails. You could
try to isolate the sass code, to understand what exactly is causing the
problem, it would be easier to find a workaround.

Original comment by alex.obj...@gmail.com on 14 May 2014 at 12:17

GoogleCodeExporter commented 9 years ago
Thank you! If i found solution i commit code here

Original comment by valentin...@gmail.com on 14 May 2014 at 12:23

GoogleCodeExporter commented 9 years ago

Original comment by alex.obj...@gmail.com on 18 Jun 2014 at 11:06