Skip to content
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

added option to fix relative urls #186

Merged
merged 3 commits into from Mar 12, 2017

Conversation

sontek
Copy link
Contributor

@sontek sontek commented Mar 9, 2017

This is rebased from bendytree (#124)

@jsf-clabot
Copy link

jsf-clabot commented Mar 9, 2017

CLA assistant check
All committers have signed the CLA.

@joshwiens
Copy link
Member

@sontek - You will need to sign the CLA.

@bebraw @michael-ciniawsky - We are going with this in favor of #124 as a prelude to @john-bai's work in #165 which is waiting on chrome-canary updates to propagate down.

fixUrls.js Outdated
.replace(/^'(.*)'$/, function(o,$1){ return $1; });

//already a full url? no change
if (/^(data:|http:\/\/|https:\/\/|file:\/\/\/|\/\/)/i.test(unquotedOrigUrl))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please check the comment from @john-bai regarding urls with hash fragments #124 (comment)

@romulof fixed this error here: romulof@c695210

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed! I added a test to show this change, It doesn't touch any hash URLs now

@sontek
Copy link
Contributor Author

sontek commented Mar 9, 2017

@d3viant0ne Yeah, I signed it but I'm not sure if @bendytree tree has. How do you check that?

@bebraw
Copy link
Contributor

bebraw commented Mar 9, 2017

Good point. @bendytree probably has to sign too unless his commit is lost from the history (probably something to avoid until we hear back from him).

@sontek
Copy link
Contributor Author

sontek commented Mar 9, 2017

Only thing I don't like about the PR from @romulof is that it moves from taking a currentUrl arg to using window directly. What is your opinion on that? Do you like the change?

@bebraw
Copy link
Contributor

bebraw commented Mar 9, 2017

The window bit will fair server side most likely. But do people use style-loader on server side? It doesn't make a lot of sense there.

@sontek
Copy link
Contributor Author

sontek commented Mar 9, 2017

Ok, I pulled in the code and updated the tests to mock window.location to work with it but it looks like the code is incomplete. It didn't provide a test to prove it was working but it seems to have broke the existing tests as well.

If someone wants to play with getting the @romulof code working, the branch of it is here:

sontek#1

But its doing things like location.protocol + location.host which won't work because location.protocol returns without // in it.

addStyles.js Outdated
@@ -35,6 +36,9 @@ module.exports = function(list, options) {
// By default, add <style> tags to the bottom of <head>.
if (typeof options.insertAt === "undefined") options.insertAt = "bottom";

// Fix urls defaults to false
if (typeof options.fixUrls === "undefined") options.fixUrls = false;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There was a discussion in a previous PR about this. It seems like it makes sense to enable this by default. Otherwise we get broken CSS and no advice from Webpack on how to fix it.

Just to be safe and not break previous workarounds we could add few checks:

  1. that sourceMaps are enabled
  2. output.publicPath is not set

@ekulabuhov
Copy link
Member

@sontek thanks for the PR. Could you also copy the README changes and the unit tests.

I can see a commit that says "Mochaify unit tests" but it looks you've just deleted the contents? 🤔

Copy link
Member

@michael-ciniawsky michael-ciniawsky left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See @ekulabuhov @d3viant0ne comments and maybe a better name for fixURL 😛

@sontek
Copy link
Contributor Author

sontek commented Mar 9, 2017

How should hash URLs work?

if you get #bg.jpg do you fix it or just leave it as #bg.jpg?

@sontek
Copy link
Contributor Author

sontek commented Mar 9, 2017

How should double slash URLs work? if you have //a/b.jpg do you add protocol onto it?

@sontek
Copy link
Contributor Author

sontek commented Mar 9, 2017

@ekulabuhov Tests are there now, I haven't moved README in yet because there is discussion of defaulting it to true which means the docs won't be correct.

@sontek
Copy link
Contributor Author

sontek commented Mar 9, 2017

For my questions above:

both // urls and # urls stay untouched.

@sontek
Copy link
Contributor Author

sontek commented Mar 9, 2017

@d3viant0ne I believe I've made all the changes you requested.

@ekulabuhov I've made most of the changes you've requested. Only one I'm not sure of is how to check if publicPath is defined. I have it auto turning fixUrls on if they haven't set fixUrls and they have sourceMap enabled though.

@sontek sontek force-pushed the fix-urls branch 2 times, most recently from 53863ae to 43941b2 Compare March 9, 2017 19:45
@joshwiens
Copy link
Member

Definitely want @bebraw to take a look at this one as well before it goes anywhere.

@joshwiens
Copy link
Member

joshwiens commented Mar 10, 2017

For reference, @sontek is the only one that needs to sign the CLA. This is a new branch with a single committer, the dead pull request from the user in question will simply be closed.

The comment about the hash fix is related to @john-bai's comment in the dead pull request who has this problem well researched.

As far as using window, this will fail server side which may cause issues in angular-universal or any other server side rendering.

Case in point: #167

README.md Outdated
@@ -72,6 +72,10 @@ By default, the style-loader appends `<style>` elements to the end of the `<head

If defined, the style-loader will re-use a single `<style>` element, instead of adding/removing individual elements for each required module. **Note:** this option is on by default in IE9, which has strict limitations on the number of style tags allowed on a page. You can enable or disable it with the singleton query parameter (`?singleton` or `?-singleton`).

#### `fixUrls`

If fixUrls and sourceMaps are both enabled, relative urls will be converted to absolute urls right before the css is injected into the page. This resolves [an issue](https://github.com/webpack/style-loader/pull/96) where relative resources fail to load when source maps are enabled. You can enable it with the fixUrls query parameter (`?fixUrls`).
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Based on the description it feels like there could be a better name for the parameter. How about convertToAbsoluteUrls? fixUrls feels too vague and you have to look it up to understand what it fixes exactly.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is general consensus that convertToAbsoluteUrls is the way we are going? I have no strong opinions about this as long as I get the feature so I can stop using a fork :)

@ekulabuhov
Copy link
Member

@d3viant0ne on the window debate: style-loader is a runtime loader. For SSR the best way to go - is to capture all CSS statically at build-time. extract-text-plugin seems to be the most common way to do it. Currently style-loader will intentionally throw an exception if used outside the browser.

@sontek
Copy link
Contributor Author

sontek commented Mar 11, 2017

@michael-ciniawsky I believe I've made all the changes you requested as well

Copy link
Member

@joshwiens joshwiens left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I hate to ask this after all the back and forth but given Chore 57 rolled out globally yesterday, would it not be better to just get #165 up to date and landed as the original PR this is based off of is just a stop gap for the above.

Or are we going with this now & #165 in the next major? This at least improves the relative URL issue for the current major release series.

@ekulabuhov
Copy link
Member

I would prefer #165 because it removes code, decreasing the complexity and chance for bugs creeping in. But let's check if #165 actually works before closing this one.

@sontek
Copy link
Contributor Author

sontek commented Mar 11, 2017

Yeah, my only concern is that this PR comes with a pretty large amount of tests that prove what its doing is correct and will work. It also works with new any version of Chrome. #165 hasn't been proven to work, comes with no tests, and only works with 57+

@joshwiens
Copy link
Member

joshwiens commented Mar 11, 2017

Yeah, that's pretty much what I am thinking @sontek. Realistically, #165 is going to take some time to update and properly vet.

This issue has been a pain point for a non-trivial amount of time and this pull request solves a problem in the current 0.x.x version range and allows the chrome version to lag a little bit without requiring everyone to update to what should probably a Major based on the browser requirement as Evergreen doesn't necessarily mean up to date.

We can push in this PR & any other of value to this Major range, then start merging in features / fixes that will be included in the 1.0.0. Currently that includes ...

1.) #165 will need to be updated to account for what is going to change here & then merged.
2.) Upgrade to webpack-defaults
3.) Any viable PR currently open & of value.

1.0.0-beta.0 will then begin release validation and be published on the @beta dist-tag.

As a side note, given the above regarding value to the current major range and the amount of back and forth @sontek has filtered through to get this ready, simply closing this would quite frankly be rude. Which is not something we are going to do.

@joshwiens joshwiens added this to the 0.14.0 milestone Mar 11, 2017
@joshwiens joshwiens removed this from Feature in Dashboard Mar 11, 2017
@michael-ciniawsky michael-ciniawsky merged commit 1ae44f8 into webpack-contrib:master Mar 12, 2017
@sontek sontek deleted the fix-urls branch March 12, 2017 00:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants