-
Notifications
You must be signed in to change notification settings - Fork 2.3k
[enh] Static file with hashes #4466
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
Conversation
|
There are hashes for the images in Leaflet. The leaflet.css file references these images, and if their URLs change, the .map file will break. One solution is to recompile leaflet.css from the .less files; the other solution is to avoid adding the hashes. Commit The code is not very clean:
but this issue aside, it seems to be good enough. |
| actual_filename = f"themes/{theme_dir.name}/{rel_actual_filename}" | ||
| results[logical_filename] = actual_filename | ||
| else: | ||
| # assets.json does not exist |
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 simple theme is the only theme, but the code still supports multiple themes --> the existing themes won't have the assets.json files, so the following code is here for backward compatibility (= for custom themes in the different forks).
|
Isn't it simpler/better to use index f8d3e6757..45ae8a574 100644
--- a/client/simple/vite.config.js
+++ b/client/simple/vite.config.js
@@ -107,9 +107,9 @@ export default defineConfig({
// file naming conventions / pathnames are relative to outDir (PATH.dist)
output: {
- entryFileNames: "[name].js",
- chunkFileNames: "[name].js",
- assetFileNames: "[name].[ext]",
+ entryFileNames: "[name].[hash].js",
+ chunkFileNames: "[name].[hash].js",
+ assetFileNames: "[name].[hash].[ext]",
// Vite does not support "rollupOptions.output.sourcemap".
// Please use "build.sourcemap" instead.
// sourcemap: true,with {
"js/searxng.head.js": {
"file": "js/searxng.head.min.5vbFT7cW.js",
"name": "js/searxng.head.min",
"src": "js/searxng.head.js",
"isEntry": true
},
"js/searxng.js": {
"file": "js/searxng.min.CoHvYy0-.js",
"name": "js/searxng.min",
"src": "js/searxng.js",
"isEntry": true
},
"less/rss.less": {
"file": "css/rss.min.aJKEdM9t.css",
"src": "less/rss.less",
"isEntry": true
},
"less/style-ltr.less": {
"file": "css/searxng.min.vfsuff-7.css",
"src": "less/style-ltr.less",
"isEntry": true
},
"less/style-rtl.less": {
"file": "css/searxng-rtl.min.DI7zUmR_.css",
"src": "less/style-rtl.less",
"isEntry": true
}
} |
|
The custom code in this PR add a hash for the all the files (with explicite exceptions)
|
|
At the moment, this is not possible because we are copying the assets (images). With the PR: we moved to vite, but at the moment we are not using it properly yet, we are currently only doing with it what we did before with grunt. For example, we currently only use the build process and assets such as images are copied .. the path to real client development is not yet complete (the migration to vite is not finished). As soon all objects are managed by vite at some point, then all this is possible, but in the current state the framework is not aware of the connection between CSS, JS and assets. |
|
Ok, I don't know what you want to prioritize. |
Cache busting has caused serious problems for users in the past, here are two examples: - searxng#4419 - searxng#4481 And it makes development and deployment significantly more complex because it binds the client side to the server side: - searxng#4466 In the light of a decoupled development of the WEB clients from the server side: - searxng#4988 is it appropriate to abandon this feature. In fact, it has been ineffective since searxng#4436 anyway. However, the benefit has always been questionable, since at best only a few kB of data are saved (at least in the context of an image_proxy, the effect is below the detection limit). Ultimately, the client is responsible for caching. Related: https://github.com/searxng/searxng/issues?q=label%3A%22clear%20browser%20cache%22 Closes: searxng#4466 Closes: searxng#1326 Closes: searxng#964 Signed-off-by: Markus Heiser <markus.heiser@darmarit.de>
Cache busting has caused serious problems for users in the past, here are two examples: - searxng#4419 - searxng#4481 And it makes development and deployment significantly more complex because it binds the client side to the server side: - searxng#4466 In the light of a decoupled development of the WEB clients from the server side: - searxng#4988 is it appropriate to abandon this feature. In fact, it has been ineffective since searxng#4436 anyway. However, the benefit has always been questionable, since at best only a few kB of data are saved (at least in the context of an image_proxy, the effect is below the detection limit). Ultimately, the client is responsible for caching. Related: https://github.com/searxng/searxng/issues?q=label%3A%22clear%20browser%20cache%22 Closes: searxng#4466 Closes: searxng#1326 Closes: searxng#964 Signed-off-by: Markus Heiser <markus.heiser@darmarit.de>
What does this PR do?
Look at the commit cc0ff46
The code takes core of:
map files
{ "js/leaflet.js": "js/leaflet.db49d009.js", "js/leaflet.js.map": "js/leaflet.db49d009.js.map", }link inside JS and CSS:
leaflet.SEARXNG_HASH.cssis replaced byleaflet.db49d009.jsWARNING: the code does not handle the fact that we can have two files with the same name, for example
img/big/searxng.pngandimg/small/searxng.png.TODO:
basename.SEARX_HASH.extensionthe right way ?make static.build.restoreneeds some care to manage files with hashesWhy is this change important?
How to test this PR locally?
make runAuthor's checklist
Feel free to close / update / whatever this PR
Related issues