-
-
Notifications
You must be signed in to change notification settings - Fork 8.5k
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
Adding fingerprint to compiled css #694
Conversation
Deploy preview for docusaurus-preview ready! Built with commit 59525aa |
This is still a WIP. I am not sure if adding a hash.txt file on the build folder is the right and cleanest approach in order to supply the CSS hash string to the test suites |
Modifying build-file test case to read hashed CSS
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.
@gedeagas Thanks for the PR! However, I don't agree with this approach that a random hash is generated on every build. I think the better approach is to generate the hash based on file contents instead so that if the file contents doesn't change, the hash remains the same and loaded assets can be cached.
lib/__tests__/build-files.test.js
Outdated
@@ -88,10 +88,14 @@ test('Generated table of contents', function() { | |||
}); | |||
|
|||
test('Concatenated CSS files', function() { | |||
let hash = fs.readFileSync( | |||
buildDir + '/' + siteConfig.projectName + '/hash.txt', |
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 there a need for hash.txt
?
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 hash.txt file is needed in order to supply the CSS hash string to the test suites. but this is only a temporary fix because as I say in my previous comment adding a hash.txt file on the build folder is not the right nor cleanest approach to this. Do you have any suggestion on this?
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.
lib/core/Head.js
Outdated
<link | ||
rel="stylesheet" | ||
href={ | ||
this.props.config.baseUrl + 'css/' + this.props.hash + '.main.css' |
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.
Isn't it more common to have main.[hash].css
? At least that's the webpack convention.
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.
Got it
lib/server/generate.js
Outdated
|
||
commander.option('--skip-image-compression').parse(process.argv); | ||
|
||
// create secure crypto hash for css | ||
var secureHash = crypto.randomBytes(10).toString('hex'); |
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.
Use const
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.
Got it
Will try to implement hashing based on the content later today. Thank you for your suggestion @yangshun |
…nvention of the ccs file into webpack like convention.
How do you think @yangshun ? |
lib/core/Head.js
Outdated
rel="stylesheet" | ||
href={this.props.config.baseUrl + 'css/main.css'} | ||
/> | ||
{this.props.hash ? ( |
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.
Seems like we can save few lines of code by removing double re-use of <link ....
Example:
href = {`${this.props.config.baseUrl}css/main${this.props.hash ? this.props.hash : ''}.css`}
or ( i prefer this )
href = {this.props.config.baseUrl + 'css/main.' + this.props.hash ? this.props.hash : '' + '.css'}
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.
woah, this not crossed my mind before @endiliey. i think your second option is what we should do
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.
Actually @yangshun told me template literal string is easier to read
this.props.hash ?
`${this.props.config.baseUrl}css/main${this.props.hash}.css` :
`${this.props.config.baseUrl}css/main.css` :
@gedeagas Hi! I think we are just waiting for the suggested change and a rebase since there are some conflicts now. |
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 make the suggested changes (refactor), resolve the merge conflicts & provide a test plan whereby the same build(no changes in file content) produces the same hash and different build produces different hash
Hi @JoelMarcey, I will be working on this today. Sorry for the delay. crazy week at the office. Got it @endiliey |
dbb6441
to
a5c13f2
Compare
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 patched & refactored @gedeagas PR. It should be working now. I tested with 5 different build, and the same build(no changes in file content) produces the same hash and different build produces different hash
Test Plan
- No change on main.css
Result:main.1ac8d6325f8699c1b86a3b61854ad4e82f880891.css
- No change on main.css
Result:main.1ac8d6325f8699c1b86a3b61854ad4e82f880891.css
- Change main.css
Result:main.0a037522d71b06ecf631742f19a4acd6fbd04ce6.css
footer .social {
padding: 15px 0;
}
- Change main.css
Result:main.d06b7994781743bfed253162cc0a59c3c7e0452d.css
footer .social {
padding: 25px 0;
}
- Change main.css back to original
Result:main.1ac8d6325f8699c1b86a3b61854ad4e82f880891.css
One thing we need to test is whether the separate css works. For example, Prettier has a separate playground that hardcodes the CSS path there. Will their code break when we introduce this? |
Another thought - if the playground page referenced main.css (without hash)
it would fail right?
If not, then I think we can ship this.
…On Tue, Jun 19, 2018 at 4:00 AM Endilie Yacop Sucipto < ***@***.***> wrote:
@yangshun <https://github.com/yangshun>
Just tried prettier website. Seems that separate css work as per normal
[image: separate css]
<https://user-images.githubusercontent.com/17883920/41593505-df384e26-73f2-11e8-81eb-21072966dcd3.PNG>
Only main.css get hashed
[image: maincss]
<https://user-images.githubusercontent.com/17883920/41593531-f4cc5f02-73f2-11e8-9570-5942d498fe3d.PNG>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#694 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABQRHVjkak2FQ5rNK1OtHUu_c8jUCQTlks5t-NnIgaJpZM4UK5Y->
.
|
Yes, if the playground page referenced main.css (without hash). It would fail. Without this PR
With this PR it will be something like
It's a given that static html page like this didn't know the hash and won't be able to reference All other pages (docs, blogs, *.js) won't have a problem because we inject the main.css (with hash) in However, a way for static HTML pages to use our own Docusaurus site styles, header and footer is to set |
So if we landed this, then Prettier would have to update their site or the playground would break? Just making sure I understand that correctly. |
@JoelMarcey it won't break prettier's website because they never reference Docusaurus |
I just checked https://docusaurus.io/docs/en/custom-pages#adding-static-pages
Seems that this will break someone's else code 😂
|
I thought of that too. But doesn't seem to be an elegant solution. If this feature is not that important shall we hold off for now? |
I agree, it defeats the purpose of fingerprinting. I think this feature is not that important (sorry @gedeagas 😢). It might become important if we focus on building offline version of Docusaurus. Let's put this on hold |
For those who deploy to CDN and still looking for a workaround, we currently use the following lines in our deployment script to add fingerprint to CSS, before pushing to S3:
hope it's helpful |
Closing this in favor of v2 implementation |
Motivation
As stated here #439 fingerprinting the CSS file is necessary when the website use CDN. It is also necessary to fingerprint our static file because in PWAs they cache the content via paths.
Have you read the Contributing Guidelines on pull requests?
Yes