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

Proposal for url(...) rewriting #2927

Open
wants to merge 39 commits into
base: main
Choose a base branch
from

Conversation

DeMoorJasper
Copy link

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.

proposal/custom-url-resolution.md Outdated Show resolved Hide resolved
proposal/custom-url-resolution.md Outdated Show resolved Hide resolved
proposal/custom-url-resolution.md Outdated Show resolved Hide resolved
proposal/custom-url-resolution.md Outdated Show resolved Hide resolved
proposal/custom-url-resolution.md Outdated Show resolved Hide resolved
@DeMoorJasper
Copy link
Author

@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.
Also made the rewriteUrl plugin also responsible of resolving as you mentioned the importer cannot currently handle this.

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.

Copy link
Contributor

@nex3 nex3 left a 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?

proposal/custom-url-resolution.md Outdated Show resolved Hide resolved
proposal/custom-url-resolution.md Outdated Show resolved Hide resolved
proposal/custom-url-resolution.md Outdated Show resolved Hide resolved
@DeMoorJasper
Copy link
Author

@nex3 originally I created a proposal based on that comment with the only real difference being using url instead of sass-url but as it would still be blocked by importer as you already mentioned the import api would also need to be changed.

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 sass-url again, that's the only real difference, besides the importer which can always be updated later.

I was also thinking about only rewriting url's that start with file:// based on your comment, which I think is a wonderful idea, just not sure if this is something that should be implemented in here or be a choice for the plugins.

Copy link
Contributor

@nex3 nex3 left a comment

Choose a reason for hiding this comment

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

Sorry for the long delay, I missed your response. For future reference, if you click the sync icon under reviewers, it will let your reviewer know the PR is ready for another look.

proposal/custom-url-resolution.md Outdated Show resolved Hide resolved
proposal/custom-url-resolution.md Outdated Show resolved Hide resolved
proposal/custom-url-resolution.md Show resolved Hide resolved
proposal/custom-url-resolution.md Outdated Show resolved Hide resolved
@DeMoorJasper
Copy link
Author

DeMoorJasper commented Nov 12, 2020

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?

Copy link
Contributor

@nex3 nex3 left a 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.

proposal/custom-url-resolution.md Outdated Show resolved Hide resolved
proposal/custom-url-resolution.md Outdated Show resolved Hide resolved
proposal/custom-url-resolution.md Outdated Show resolved Hide resolved
proposal/custom-url-resolution.md Outdated Show resolved Hide resolved
proposal/custom-url-resolution.md Outdated Show resolved Hide resolved
proposal/custom-url-resolution.md Outdated Show resolved Hide resolved
jarham added a commit to online-inquiry-tool/oit that referenced this pull request Aug 25, 2022
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
```TypeScript
let sassOptions = {
// Rewrite urls asynchronously
rewriteUrl: async (urlReference: { file: string, url: string }, done: (error: Error | null, url: string | null) => void): void => {
Copy link
Contributor

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)

Copy link
Author

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

}
```

### Using Variables
Copy link
Contributor

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.

Copy link
Author

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

import * as sass from 'sass';

const options = {
rewriteUrl: sass.url.inline()
Copy link
Contributor

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.

Copy link
Author

Choose a reason for hiding this comment

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

Right, will update

@nex3
Copy link
Contributor

nex3 commented Jul 17, 2023

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 nex3 closed this Jul 17, 2023
@DeMoorJasper
Copy link
Author

@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

@nex3 nex3 reopened this Jul 17, 2023
Copy link
Contributor

@nex3 nex3 left a 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
Copy link
Contributor

Choose a reason for hiding this comment

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

Style nit

Suggested change
# 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)_
Copy link
Contributor

Choose a reason for hiding this comment

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

Style nit:

Suggested change
_[(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.
Copy link
Contributor

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.
Copy link
Contributor

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.
Copy link
Contributor

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.
Copy link
Contributor

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.
Copy link
Contributor

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.

Comment on lines +61 to +68
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
Copy link
Contributor

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.
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants