-
Notifications
You must be signed in to change notification settings - Fork 2.2k
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
Proposal for url(...)
rewriting
#2927
base: main
Are you sure you want to change the base?
Conversation
@nex3 thanks for reviewing this proposal, I've changed it quite substantially based on your feedback. Removed the ability to have multiple plugins in a row as it didn't really make sense after seeing your comment and thinking about it a bit more. Let me know if you think any other things need to change or if there's anything else I can help to move this forward. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was reading over #2535 again, and #2535 (comment) in particular where I outlined the general approach the Sass core team had decided on for this. The approach you're describing here differs substantially from the one that comment describes. What's the reasoning behind that difference?
@nex3 originally I created a proposal based on that comment with the only real difference being using I figured this approach would probably be easier to implement for now and probably solve the problem just as good for most people. If you think this is a bad idea I could always change this to use I was also thinking about only rewriting url's that start with |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the review @nex3 I hope I've resolved all remarks you had, if I didn't feel free to leave some more feedback. I've also been thinking about standardising the way this gets configured, as in there should probably be a list of presets that users can utilise (inline, relative, ...). The plugin that is currently introduced in this draft is definitely still required as bundlers will probably want to overwrite the default behaviour regardless to keep track of included files. (I know we do this in Parcel for other css related languages). But a standardised way of configuring this would make it possible for users to switch between webpack, parcel and just the standard sass cli with minimal changes, not sure if you think this should be part of sass or if this is something for the future? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think standardizing a few resolvers makes sense. These should probably be exposed as standard resolver functions, or for resolvers that need extra information like relative
, a higher-order function that returns a resolver.
Old version kept: - bootstrap-icons, 1.9 changed scss to use variables in font urls which broke compatibility with vite's scss processing. bootstrap-icons seems to have valid scss, so the actual problem is with Vite (and sass not supporting url rewriting). Importing bootstrap-icons.css could be used as a workaround. See: - twbs/icons#1381 - vitejs/vite#7651 - sass/sass#1015 - sass/sass#2535 - sass/sass#2927 Updated only up to minor version: - @types/node, still using Node 16 as it's the latest LTS at this time
proposal/custom-url-resolution.md
Outdated
```TypeScript | ||
let sassOptions = { | ||
// Rewrite urls asynchronously | ||
rewriteUrl: async (urlReference: { file: string, url: string }, done: (error: Error | null, url: string | null) => void): void => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Passing a done
callback does not make sense to me. The result should be returned in the promise instead (an async function already returns a promise anyway)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Was just mimicing existing sass api's but will update
proposal/custom-url-resolution.md
Outdated
} | ||
``` | ||
|
||
### Using Variables |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This section is totally unnecessary given that sass-url
is defined as a function and not as a custom language construct. All functions are working with the value of their argument without having any way to know how it was produced.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It was just to highlight another use-case or the possibility of this. But I guess that's better left for docs, will remove this
proposal/custom-url-resolution.md
Outdated
import * as sass from 'sass'; | ||
|
||
const options = { | ||
rewriteUrl: sass.url.inline() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should be rewriteUrl: sass.url.inline
. We want to pass the function as the value of the option, not calling it.
There is no need to make it a function returning another function IMO.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, will update
Since this has had outstanding comments from @stof for several months, I'm going to close it out for now. I'm happy to re-open if @DeMoorJasper wants to come back to it in the future, and I'm also happy to review another PR if someone else wants to take this on. |
@nex3 sorry totally missed those comments, probably got lost in notifications as I usually just see a lot of "bump" responses to the linked issue instead of any feedback here. But fixed the feedback on my fork, lemme know if I need to do something to get this moving forward again |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've added a few comments. These should be plenty to work on for now; I'll take a look again once you've addressed them.
@@ -0,0 +1,230 @@ | |||
# Custom url resolution: Draft 1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Style nit
# Custom url resolution: Draft 1 | |
# Custom URL Resolution: Draft 1 |
@@ -0,0 +1,230 @@ | |||
# Custom url resolution: Draft 1 | |||
|
|||
_[(Issue)](https://github.com/sass/sass/issues/2535)_ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Style nit:
_[(Issue)](https://github.com/sass/sass/issues/2535)_ | |
*([Issue](https://github.com/sass/sass/issues/2535))* |
This matches the style of other proposals.
|
||
> This section is non-normative. | ||
|
||
Many css features require the use of a sass-url reference to reference resources from outside the sass files, however these files also need to exist on the eventual output directory and server. To ensure the references are valid, the sass API should allow for the user to provide a way to remap and/or inline these resources. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please wrap lines at 80 characters.
|
||
> This section is non-normative. | ||
|
||
Many css features require the use of a sass-url reference to reference resources from outside the sass files, however these files also need to exist on the eventual output directory and server. To ensure the references are valid, the sass API should allow for the user to provide a way to remap and/or inline these resources. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please use proper capitalization: "CSS", "Sass", etc. Also, code-quote any use of Sass or CSS identifiers or syntax such as sass-url
.
|
||
> This section is non-normative. | ||
|
||
Many css features require the use of a sass-url reference to reference resources from outside the sass files, however these files also need to exist on the eventual output directory and server. To ensure the references are valid, the sass API should allow for the user to provide a way to remap and/or inline these resources. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The background section is supposed to describe the world as it exists today to make the case for a new feature. Saying that we "require the use of a sass-url reference" doesn't make sense, because such a thing doesn't exist currently. What is the problem that exists and that needs to be solved?
|
||
> This section is non-normative. | ||
|
||
This proposal defines a standardized way to remap the sass-url references to the final location on the server or inline reference. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Again, you're saying "the sass-url references" without explaining at all what sass-url
is or does.
|
||
This proposal defines a standardized way to remap the sass-url references to the final location on the server or inline reference. | ||
|
||
This is accomplished by running sass-url references through the url rewriting plugin if a url rewriting plugin has been defined. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is "a URL-rewriting plugin"? Where and how are they defined? Are there any built-in ones?
This is just the summary so it doesn't need to be meticulously precise, but this is extremely vague. You need to give a reader a sense of the specifics of your proposal so that they can evaluate it without needing to read the entire spec, not just say "here's the problem, this proposal will solve it". Think of this as a draft of the user-facing documentation that will explain how to use the new feature.
Whenever a sass-url reference is encountered in a sass file the following steps should be executed: | ||
|
||
- A sass-url reference is encountered in the sass file | ||
- From the url function we extract the parameter value | ||
- Rewrite the parameter value if it contains any variables ([see using variables](#using-variables)) | ||
- Pass the parameter value to the url rewrite plugin along with the canonical url of the current sass file | ||
- This plugin than returns a string or calls the done callback with a string value, if it returns anything else or nothing it should throw an error ([see JavaScript API](#javascript-api)) | ||
- The new url value that we received from the url rewrite plugin than gets used to replace the original url value |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not written in a standard spec style. I recommend looking at other function definitions under spec/ and accepted/ to get a better idea of how to write this.
|
||
## Function | ||
|
||
This proposal introduces logic for a new function: `sass-url("...")`, this function allow users to define a url that gets rewritten based on the config to ensure it can be loaded correctly from the browser. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the sort of thing that would be better in the summary. It does introduce the concept of a sass-url
function (that's good!), but it's mostly just a nonspecific explanation of its general purpose. It's also not clear what "the config" refers to here.
This PR includes a proposal on how to handle rewriting url's as discussed in issue #2535 for some time now.
Hopefully this helps move things forward a bit on this issue, any feedback is very welcome.
If there's anything else I can do to help this move forward feel free to ask.