feat: Use unversioned frontend asset paths #25994
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
billyvg
force-pushed
the
build/deploy/frontend-only-deploys
branch
from
0c995d0 to
a638e7c
Compare
billyvg
force-pushed
the
build/deploy/frontend-only-deploys
branch
from
a638e7c to
8863267
Compare
billyvg
force-pushed
the
build/deploy/frontend-only-deploys
branch
from
8863267 to
cef276d
Compare
billyvg
force-pushed
the
build/deploy/frontend-only-deploys
branch
from
cef276d to
d5707c7
Compare
billyvg
force-pushed
the
build/deploy/frontend-only-deploys
branch
from
d5707c7 to
7219708
Compare
billyvg
changed the base branch from
master
to
build/deploy/frontend-only-deploys-remove-webpack-manifest
billyvg
changed the base branch from
build/deploy/frontend-only-deploys-remove-webpack-manifest
to
build/webpack/refactor-to-load-vendor-from-app-entrypoint-try-2
billyvg
force-pushed
the
build/deploy/frontend-only-deploys
branch
from
7219708 to
0acf716
Compare
billyvg
force-pushed
the
build/webpack/refactor-to-load-vendor-from-app-entrypoint-try-2
branch
2 times, most recently
from
5b54806 to
294b927
Compare
billyvg
force-pushed
the
build/webpack/refactor-to-load-vendor-from-app-entrypoint-try-2
branch
2 times, most recently
from
ee4f9d9 to
7bafdaa
Compare
Base automatically changed from
build/webpack/refactor-to-load-vendor-from-app-entrypoint-try-2
to
master
June 23, 2021 21:56
billyvg
force-pushed
the
build/deploy/frontend-only-deploys
branch
from
264974c to
8419b55
Compare
billyvg
changed the title
| @@ -130,7 +130,6 @@ | |||
| "u2f-api": "1.0.10", | |||
| "webpack": "5.40.0", | |||
| "webpack-cli": "4.7.2", | |||
| "webpack-manifest-plugin": "^3.1.1", | |||
|
Tested this for on-prem using 2 images (one normal and one with an update to the background color as a test) -- the frontend assets loaded as expected |
billyvg
force-pushed
the
build/deploy/frontend-only-deploys
branch
from
e270bae to
9bd822d
Compare
billyvg
changed the base branch from
master
to
build/webpack/organize-webpack-outputs
Base automatically changed from
build/webpack/organize-webpack-outputs
to
master
June 29, 2021 16:55
This inverts the relationship between inline scripts in templates and our main js app bundle. Previously, the templates assume that certain bundles are loaded synchronously. We also expose certain components in the app bundle via globals (`SentryApp`). This would no longer work if (when) we make our bundles loaded async. Instead of exposing components through globals, allow templates to queue up predefined tasks (there are some future optimizations here as I do not believe these other django templates that extend from `layout.html` need the main app bundle). After we render the SPA to the DOM, we will iterate through `__onSentryInit` and perform the necessary initializations.
…ut it being loaded async
billyvg
force-pushed
the
build/deploy/frontend-only-deploys
branch
from
9bd822d to
12799d3
Compare
billyvg
added a commit
that referenced
this pull request
Jun 29, 2021
billyvg
added a commit
that referenced
this pull request
Jul 1, 2021
This reverts commit 3228492. This builds on top of #25744 where we refactored our JS entry points to be lightweight and to use dynamic imports (via webpack) to load the rest of the JS application. This PR will now remove the need for the backend to be updated in order to release a new frontend. This will allow us to have frontend-only deploys which should complete much faster than a full deploy. We accomplish this by removing the webpack manifest plugin introduced in #25234, where we previously were versioning by a release string in the asset path. These unversioned asset files will be served using a [`Cache-Control: no-cache`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control#cacheability) header which tells clients that they need to check against the origin server to see if the asset has changed, if it has not, they can use their cached copy. These unversioned files will end up changing quite frequently with every release, but they should be relatively small. They contain the webpack runtime that allows us to load the rest of our application bundles, which are versioned by a hash of their contents. These versioned chunks will have a long-term `max-age` for caching as the hash in the file name will serve to cache bust. Note: this was reverted in #25994 as it broke production due to our CDN having cached an old asset due to a cache misconfiguration during development. This was also not caught in staging because we needed to change the asset paths for staging deploys to avoid clobbering production assets.
billyvg
added a commit
that referenced
this pull request
Jul 1, 2021
This reverts commit 3228492. This builds on top of #25744 where we refactored our JS entry points to be lightweight and to use dynamic imports (via webpack) to load the rest of the JS application. This PR will now remove the need for the backend to be updated in order to release a new frontend. This will allow us to have frontend-only deploys which should complete much faster than a full deploy. We accomplish this by removing the webpack manifest plugin introduced in #25234, where we previously were versioning by a release string in the asset path. These unversioned asset files will be served using a [`Cache-Control: no-cache`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control#cacheability) header which tells clients that they need to check against the origin server to see if the asset has changed, if it has not, they can use their cached copy. These unversioned files will end up changing quite frequently with every release, but they should be relatively small. They contain the webpack runtime that allows us to load the rest of our application bundles, which are versioned by a hash of their contents. These versioned chunks will have a long-term `max-age` for caching as the hash in the file name will serve to cache bust. Note: this was reverted in #25994 as it broke production due to our CDN having cached an old asset due to a cache misconfiguration during development. This was also not caught in staging because we needed to change the asset paths for staging deploys to avoid clobbering production assets.
billyvg
added a commit
that referenced
this pull request
Jul 7, 2021
This reverts commit 388edc8. This builds on top of #25744 where we refactored our JS entry points to be lightweight and to use dynamic imports (via webpack) to load the rest of the JS application. This PR will now remove the need for the backend to be updated in order to release a new frontend. This will allow us to have frontend-only deploys which should complete much faster than a full deploy. We accomplish this by removing the webpack manifest plugin introduced in #25234, where we previously were versioning b y a release string in the asset path. These unversioned asset files will be served using a [`Cache-Control: no-cache`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache -Control#cacheability) header which tells clients that they need to check against the origi n server to see if the asset has changed, if it has not, they can use their cached copy. Th ese unversioned files will end up changing quite frequently with every release, but they sh ould be relatively small. They contain the webpack runtime that allows us to load the rest of our application bundles, which are versioned by a hash of their contents. These versione d chunks will have a long-term `max-age` for caching as the hash in the file name will serv e to cache bust. Note: this was reverted in #25994 as it broke p roduction due to our CDN having cached an old asset due to a cache misconfiguration during development. This was also not caught in staging because we needed to change the asset path s for staging deploys to avoid clobbering production assets, and the staging path was not p reviously cached. Requires #26987
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This builds on top of #25744 where we refactored our JS entry points to be lightweight and to use dynamic imports (via webpack) to load the rest of the JS application.
This PR will now remove the need for the backend to be updated in order to release a new frontend. This will allow us to have frontend-only deploys which should complete much faster than a full deploy. We accomplish this by removing the webpack manifest plugin introduced in #25234, where we previously were versioning by a release string in the asset path. These unversioned asset files will be served using a
Cache-Control: no-cacheheader which tells clients that they need to check against the origin server to see if the asset has changed, if it has not, they can use their cached copy. These unversioned files will end up changing quite frequently with every release, but they should be relatively small. They contain the webpack runtime that allows us to load the rest of our application bundles, which are versioned by a hash of their contents. These versioned chunks will have a long-termmax-agefor caching as the hash in the file name will serve to cache bust.