Root-relative URLs do not work for JS files #287
Comments
|
Forgot to mention: I created a simple test repo to illustrate the problem at https://github.com/davidtheclark/uncss-jsdom-test. |
I agree with @vseventer. I don't know if/how this is possible via PhantomJS, however, in jsdom, this could be done via
I will submit a patch to the jsdom branch when I get a chance (unless someone gets there before me). When it is merged to the jsdom branch, I will publish a new version of |
|
Sorry so long; I finally got the patch released as |
|
I've just released uncss 0.15.0, which I believe should include all of the above fixes. |
|
I'm hitting this with gulp-postcss and uncss 0.15. var gulp = require('gulp');
var cssmin = require('gulp-clean-css');
var postcss = require('gulp-postcss')
var uncss = require('uncss').postcssPlugin;
var config = require('../../config').optimize.css;
gulp.task('optimize:css', function() {
return gulp.src(config.src)
.pipe(postcss(uncss(config.uncss)))
.pipe(cssmin(config.options))
.pipe(gulp.dest(config.dest));
});module.exports = {
optimize: {
css: {
uncss: {
html: [buildDir + '/**/*.html'],
htmlroot: buildDir,
ignore: [
/\w\.in/,
'.fade',
'.collapse',
'.collapsed',
'.collapsing',
/(#|\.)navbar(-[a-zA-Z]+)?/,
/(#|\.)dropdown(-[a-zA-Z]+)?/,
/(#|\.)(open)/,
// injected via JS
/disabled/,
/\.no-js/,
/\.defer/
]
},
src: buildDirAssets + '/css/*.css',
dest: buildDirAssets + '/css/',
options: {
level: {
1: {
specialComments: 0
}
}
}
}
}
};I'm simply using |
|
Oh sorry, my comment above about 'fixing this' was wrong. I was overzealous in tagging this one. No, scheme-relative and host-relative paths will not work when you are accessing local html files. If you are accessing Scheme-relative ones are also tricky, in that it's using a |
|
In the past IIRC
The thing is that things worked with 0.14.1. And I also have the canvas issue which is why I haven't updated uncss in grunt-uncss. These two issues are blockers and quite important IMO. |
|
Just to clarify, are we talking about protocol-relative URLs or root-relative URLs? |
|
Root-relative URLs. Protocol-relative URLs don't work too but that's a different issue. |
|
So, after specifying |
|
Did you investigate this issue at all, or are you just sharing it here? Do you need help debugging? What version of postcss are you using, from the postcss/package.json? Do you have a 'walkRules' in your postcss package? And from the other angle, what is the 'css' object passed into that function? Is it a valid postcss object? What methods does it have on it? |
|
@mikelambert This is an internal uncss error coming from https://github.com/giakki/uncss/blob/master/src/lib.js#L129. The postcss version would be the same as what uncss is using. postcss does have a |
|
@XhmikosR is it possible to reproduce this issue without using grunt? If so, I'd be willing to investigate if you could make a test case repo or gist. |
|
That is not with Grunt. It's with gulp-postcss and uncss. |
|
Thanks @RyanZim on volunteering on the last bit. And yes, I'm aware the uncss code is emitting the exception, and that uncss has a dependency on postcss that should contain the But yes, I am also curious what object is actually being passed into the |
|
Nah, this is with vanilla uncss 0.15, see #287 (comment) I can't find why this happens. If I could I would have said so :P I mean, the css file is there, generated with sass before the uncss task runs. The html files are there too. I can't figure out why this error. |
|
Ok thanks. Can you provide a self-contained repro case? Or can you log and share the values I requested above? Namely, what is the |
Unfortunately I cannot share the repo so if this info doesn't help, I'll need to try to make a small test case. |
|
Ok, I found it! Stupid mistake... .pipe(postcss([uncss(config.uncss)]))It needs to be an array. |
|
Glad you found it. Them bugs can be mean. Can we close this now? |
|
I think this issue is no longer valid, yeah. Root-relative files work fine with |
Root-relative URLs for JS files cause errors like this:
Error: Could not load script: "file:///test.js"/Originally posted in #280 (comment), because I thought the issue was specific to the JSDom implementation. @RyanZim informed me, though, that the same error occurs with PhantomJS, it is just quietly ignored.
@vseventer suggested:
The text was updated successfully, but these errors were encountered: