{"payload":{"feedbackUrl":"https://github.com/orgs/community/discussions/53140","repo":{"id":577388475,"defaultBranch":"main","name":"vite","ownerLogin":"thebanjomatic","currentUserCanPush":false,"isFork":true,"isEmpty":false,"createdAt":"2022-12-12T16:17:11.000Z","ownerAvatar":"https://avatars.githubusercontent.com/u/17907922?v=4","public":true,"private":false,"isOrgOwned":false},"refInfo":{"name":"","listCacheKey":"v0:1714170780.0","currentOid":""},"activityList":{"items":[{"before":"5c4691ef1189cb989a8c9719e45a04464837c9a8","after":"902b4eb9f214bd3ced79e7c5e66571741df4e1e2","ref":"refs/heads/fix/error-logging","pushedAt":"2024-04-29T09:52:48.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"thebanjomatic","name":"Adam Hines","path":"/thebanjomatic","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/17907922?s=80&v=4"},"commit":{"message":"fix(error-logging): rollup errors weren't displaying id and codeframe\n\nThe code which modified the error message to have additional context about the module id\nand code frame where the error originated was relying on the error's stack having never\nbeen accessed prior to modifying the error's message. At some point, this no longer was\ntrue for Rollup errors, and no context information was being displayed as a result other\nthan the stack trace within the rollup library that doesn't make it clear what or where\nthe problem is.\n\nThis PR changes the code that add's the id and code-frame context to the error message\nto also modify the error's stack. To do so, it attempts to extract the original stack\ntrace by removing the existing error message from error.stack if it matches, and\notherwise falls back to just displaying the stack trace with its own message since it\nvaries from the error.message.\n\nSome additional normalization was done to the error.frame field if it exists to ensure\nthat consistent padding is used in the error output. This is because the rollup code-\nframe doesn't have new-lines around it, but the esbuild one does.\n\nFixes #16539","shortMessageHtmlLink":"fix(error-logging): rollup errors weren't displaying id and codeframe"}},{"before":"0745ad17e862f6fd3c501e342a61036842b0c13c","after":"5c4691ef1189cb989a8c9719e45a04464837c9a8","ref":"refs/heads/fix/error-logging","pushedAt":"2024-04-27T01:20:08.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"thebanjomatic","name":"Adam Hines","path":"/thebanjomatic","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/17907922?s=80&v=4"},"commit":{"message":"fix(error-logging): rollup errors weren't displaying id and codeframe\n\nThe code which modified the error message to have additional context about the module id\nand code frame where the error originated was relying on the error's stack having never\nbeen accessed prior to modifying the error's message. At some point, this no longer was\ntrue for Rollup errors, and no context information was being displayed as a result other\nthan the stack trace within the rollup library that doesn't make it clear what or where\nthe problem is.\n\nThis PR changes the code that add's the id and code-frame context to the error message\nto also modify the error's stack. To do so, it attempts to extract the original stack\ntrace by removing the existing error message from error.stack if it matches, and\notherwise falls back to just displaying the stack trace with its own message since it\nvaries from the error.message.\n\nSome additional normalization was done to the error.frame field if it exists to ensure\nthat consistent padding is used in the error output. This is because the rollup code-\nframe doesn't have new-lines around it, but the esbuild one does.\n\nFixes #16539","shortMessageHtmlLink":"fix(error-logging): rollup errors weren't displaying id and codeframe"}},{"before":"b20d1426ca77efe88c4f831a76c05cea344d0225","after":"0745ad17e862f6fd3c501e342a61036842b0c13c","ref":"refs/heads/fix/error-logging","pushedAt":"2024-04-27T01:04:53.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"thebanjomatic","name":"Adam Hines","path":"/thebanjomatic","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/17907922?s=80&v=4"},"commit":{"message":"fix(error-logging): rollup errors weren't displaying id and codeframe\n\nThe code which modified the error message to have additional context about the module id\nand code frame where the error originated was relying on the error's stack having never\nbeen accessed prior to modifying the error's message. At some point, this no longer was\ntrue for Rollup errors, and no context information was being displayed as a result other\nthan the stack trace within the rollup library that doesn't make it clear what or where\nthe problem is.\n\nThis PR changes the code that add's the id and code-frame context to the error message\nto also modify the error's stack. To do so, it attempts to extract the original stack\ntrace by removing the existing error message from error.stack if it matches, and\notherwise falls back to just displaying the stack trace with its own message since it\nvaries from the error.message.\n\nSome additional normalization was done to the error.frame field if it exists to ensure\nthat consistent padding is used in the error output. This is because the rollup code-\nframe doesn't have new-lines around it, but the esbuild one does.\n\nFixes #16539","shortMessageHtmlLink":"fix(error-logging): rollup errors weren't displaying id and codeframe"}},{"before":null,"after":"b20d1426ca77efe88c4f831a76c05cea344d0225","ref":"refs/heads/fix/error-logging","pushedAt":"2024-04-26T22:33:00.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"thebanjomatic","name":"Adam Hines","path":"/thebanjomatic","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/17907922?s=80&v=4"},"commit":{"message":"fix(error-logging): rollup errors weren't displaying id and codeframe\n\nThe code which modified the error message to have additional context about the module id\nand code frame where the error originated was relying on the error's stack having never\nbeen accessed prior to modifying the error's message. At some point, this no longer was\ntrue for Rollup errors, and no context information was being displayed as a result other\nthan the stack trace within the rollup library that doesn't make it clear what or where\nthe problem is.\n\nThis PR changes the code that add's the id and code-frame context to the error message\nto also modify the error's stack. To do so, it attempts to extract the original stack\ntrace by removing the existing error message from error.stack if it matches, and\notherwise falling back to looking for the stack trace portion by searching for indented\nlines that look something like:\n    at (file://path/to/file.js\nor\n    at <annonymout>\n\nSome additional normalization was done to the error.frame field if it exists to ensure\nthat consistent padding is used in the error output.\n\nFixes #16539","shortMessageHtmlLink":"fix(error-logging): rollup errors weren't displaying id and codeframe"}},{"before":"96353ba230f932a4b4ca691b56a514294a54a88e","after":"16b9a8cbe6cd24b65579cb3cc32159545c7915ac","ref":"refs/heads/feat/cspNonce-style","pushedAt":"2024-04-18T10:27:42.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"thebanjomatic","name":"Adam Hines","path":"/thebanjomatic","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/17907922?s=80&v=4"},"commit":{"message":"docs(cspNonce): update to include <style>","shortMessageHtmlLink":"docs(cspNonce): update to include &lt;style&gt;"}},{"before":"8b92a3990a243204f422cda5da38b3af0d6357b2","after":"96353ba230f932a4b4ca691b56a514294a54a88e","ref":"refs/heads/feat/cspNonce-style","pushedAt":"2024-04-13T15:33:39.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"thebanjomatic","name":"Adam Hines","path":"/thebanjomatic","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/17907922?s=80&v=4"},"commit":{"message":"docs(cspNonce): update to include <style>","shortMessageHtmlLink":"docs(cspNonce): update to include &lt;style&gt;"}},{"before":"cac378206c994f18bf0b09ff7aa4404a7224ba6f","after":"8b92a3990a243204f422cda5da38b3af0d6357b2","ref":"refs/heads/feat/cspNonce-style","pushedAt":"2024-04-13T15:31:26.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"thebanjomatic","name":"Adam Hines","path":"/thebanjomatic","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/17907922?s=80&v=4"},"commit":{"message":"docs(cspNonce): update to include <style>","shortMessageHtmlLink":"docs(cspNonce): update to include &lt;style&gt;"}},{"before":"5822b89334b007aa1e9315ac5f9c32fea5e9a9f0","after":"259ba21739677d4e27d859483110d8775519e94a","ref":"refs/heads/fix/cspNonce-duplicates","pushedAt":"2024-04-13T15:08:14.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"thebanjomatic","name":"Adam Hines","path":"/thebanjomatic","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/17907922?s=80&v=4"},"commit":{"message":"refactor: reduce duplication, improve readability","shortMessageHtmlLink":"refactor: reduce duplication, improve readability"}},{"before":"76b0efbaecf36df2616907f9e8d8992d070d1a9d","after":"5822b89334b007aa1e9315ac5f9c32fea5e9a9f0","ref":"refs/heads/fix/cspNonce-duplicates","pushedAt":"2024-04-13T15:04:54.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"thebanjomatic","name":"Adam Hines","path":"/thebanjomatic","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/17907922?s=80&v=4"},"commit":{"message":"refactor: reduce duplication, improve readability","shortMessageHtmlLink":"refactor: reduce duplication, improve readability"}},{"before":"80795cc74382d64348228197af398e22bd20c2b1","after":"76b0efbaecf36df2616907f9e8d8992d070d1a9d","ref":"refs/heads/fix/cspNonce-duplicates","pushedAt":"2024-04-13T14:48:12.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"thebanjomatic","name":"Adam Hines","path":"/thebanjomatic","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/17907922?s=80&v=4"},"commit":{"message":"fix(cspNonce): don't overwrite existing nonce values\n\nFixes: #16414","shortMessageHtmlLink":"fix(cspNonce): don't overwrite existing nonce values"}},{"before":null,"after":"cac378206c994f18bf0b09ff7aa4404a7224ba6f","ref":"refs/heads/feat/cspNonce-style","pushedAt":"2024-04-13T14:47:01.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"thebanjomatic","name":"Adam Hines","path":"/thebanjomatic","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/17907922?s=80&v=4"},"commit":{"message":"feat: write cspNonce to style tags","shortMessageHtmlLink":"feat: write cspNonce to style tags"}},{"before":"40a03aba85ec00af0993cd32ca9e0c570201d2f4","after":"80795cc74382d64348228197af398e22bd20c2b1","ref":"refs/heads/fix/cspNonce-duplicates","pushedAt":"2024-04-13T14:44:58.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"thebanjomatic","name":"Adam Hines","path":"/thebanjomatic","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/17907922?s=80&v=4"},"commit":{"message":"feat: write cspNonce to style tags","shortMessageHtmlLink":"feat: write cspNonce to style tags"}},{"before":"3eef719b1026ffc955d0dfb9e6b24c1152d641f4","after":"40a03aba85ec00af0993cd32ca9e0c570201d2f4","ref":"refs/heads/fix/cspNonce-duplicates","pushedAt":"2024-04-12T21:07:49.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"thebanjomatic","name":"Adam Hines","path":"/thebanjomatic","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/17907922?s=80&v=4"},"commit":{"message":"fix(cspNonce): don't overwrite existing nonce values\n\nFixes: #16414","shortMessageHtmlLink":"fix(cspNonce): don't overwrite existing nonce values"}},{"before":"6c323d5b3ab3cdf81d21bbe965ed3c36aa7f0589","after":"3eef719b1026ffc955d0dfb9e6b24c1152d641f4","ref":"refs/heads/fix/cspNonce-duplicates","pushedAt":"2024-04-12T21:05:11.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"thebanjomatic","name":"Adam Hines","path":"/thebanjomatic","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/17907922?s=80&v=4"},"commit":{"message":"fix(cspNonce): don't overwrite existing nonce values\n\nFixes: #16414","shortMessageHtmlLink":"fix(cspNonce): don't overwrite existing nonce values"}},{"before":"c643a8ae9d90691d60695c6de8d1d1f32e1ea045","after":"6c323d5b3ab3cdf81d21bbe965ed3c36aa7f0589","ref":"refs/heads/main","pushedAt":"2024-04-12T21:04:58.000Z","pushType":"push","commitsCount":273,"pusher":{"login":"thebanjomatic","name":"Adam Hines","path":"/thebanjomatic","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/17907922?s=80&v=4"},"commit":{"message":"docs: SF meetup promo (#16398)","shortMessageHtmlLink":"docs: SF meetup promo (<a class=\"issue-link js-issue-link\" data-error-text=\"Failed to load title\" data-id=\"2237122597\" data-permission-text=\"Title is private\" data-url=\"https://github.com/vitejs/vite/issues/16398\" data-hovercard-type=\"pull_request\" data-hovercard-url=\"/vitejs/vite/pull/16398/hovercard\" href=\"https://github.com/vitejs/vite/pull/16398\">vitejs#16398</a>)"}},{"before":null,"after":"6c323d5b3ab3cdf81d21bbe965ed3c36aa7f0589","ref":"refs/heads/fix/cspNonce-duplicates","pushedAt":"2024-04-12T21:03:28.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"thebanjomatic","name":"Adam Hines","path":"/thebanjomatic","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/17907922?s=80&v=4"},"commit":{"message":"docs: SF meetup promo (#16398)","shortMessageHtmlLink":"docs: SF meetup promo (<a class=\"issue-link js-issue-link\" data-error-text=\"Failed to load title\" data-id=\"2237122597\" data-permission-text=\"Title is private\" data-url=\"https://github.com/vitejs/vite/issues/16398\" data-hovercard-type=\"pull_request\" data-hovercard-url=\"/vitejs/vite/pull/16398/hovercard\" href=\"https://github.com/vitejs/vite/pull/16398\">vitejs#16398</a>)"}},{"before":"b1e6557092ad6f4b90d3efb88505b2faabd3869e","after":"9b0c2167ed884b34857a96002b92d7c2a1634822","ref":"refs/heads/feat/optimize-deps-css2","pushedAt":"2024-01-24T20:46:17.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"thebanjomatic","name":"Adam Hines","path":"/thebanjomatic","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/17907922?s=80&v=4"},"commit":{"message":"feat(css): bundle css as part of optimizeDeps\n\nThis feature is intended to support component libraries that ship tree-\nshakable modules that include css imports.\n\nWhen building with Vite, if the js files within your dependencies,\ncontain css, then at build time, the css will get pulled into the app's\ncss bundles and will be tree-shaken as part of the build (if\nsideEffects: false in the dependency and the module which imported the\ncss is also dropped). For dev builds, treeshaking doesn't happen, and\ninstead, all of the css will wind up getting imported. The current\nbehavior with optimizeDeps is that the css imports are externalized and\npreserved in the resulting .js deps bundles. This can result in a lot of\ncss request being made on page load to the dev server. While css imports\nare faster to process than js imports, it still isn't ideal.\n\nThis feature extends the default preoptimized dependency bundling to\nsupport css imports from within the dependency's .js files. Esbuild\nalready supports this feature, but it does so by bundling the css to a\nsingle .css bundle that sits alongside the js bundle, and it removes all\nimports to the css files from the resulting js bundle. The implied use-\ncase is that consumers of a library built with esbuild would need to use\na style tag, or import the css file directly.\n\nSince we can't really change the semantics of how the library is\nconsumed as a result of optimizeDeps, we need to inject a single import\nstatement into the .js bundle if it has a corresponding cssBundle file\nin the esbuild metadata file. We are just appending this import\nstatement to the bottom of the file so that the sourcemaps are\nstill functional.\n\nThe end result is that the css for these dependencies will now be\nbundled into a single .css request for each dep / chunk that contains\nimports to a css file.","shortMessageHtmlLink":"feat(css): bundle css as part of optimizeDeps"}},{"before":"7fb726c9a08826a2e66f62515053c16c38eb247c","after":"b1e6557092ad6f4b90d3efb88505b2faabd3869e","ref":"refs/heads/feat/optimize-deps-css2","pushedAt":"2024-01-24T20:44:43.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"thebanjomatic","name":"Adam Hines","path":"/thebanjomatic","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/17907922?s=80&v=4"},"commit":{"message":"feat(css): bundle css as part of optimizeDeps\n\nThis feature is intended to support component libraries that ship tree-\nshakable modules that include css imports.\n\nWhen building with Vite, if the js files within your dependencies,\ncontain css, then at build time, the css will get pulled into the app's\ncss bundles and will be tree-shaken as part of the build (if\nsideEffects: false in the dependency and the module which imported the\ncss is also dropped). For dev builds, treeshaking doesn't happen, and\ninstead, all of the css will wind up getting imported. The current\nbehavior with optimizeDeps is that the css imports are externalized and\npreserved in the resulting .js deps bundles. This can result in a lot of\ncss request being made on page load to the dev server. While css imports\nare faster to process than js imports, it still isn't ideal.\n\nThis feature extends the default preoptimized dependency bundling to\nsupport css imports from within the dependency's .js files. Esbuild\nalready supports this feature, but it does so by bundling the css to a\nsingle .css bundle that sits alongside the js bundle, and it removes all\nimports to the css files from the resulting js bundle. The implied use-\ncase is that consumers of a library built with esbuild would need to use\na style tag, or import the css file directly.\n\nSince we can't really change the semantics of how the library is\nconsumed as a result of optimizeDeps, we need to inject a single import\nstatement into the .js bundle if it has a corresponding cssBundle file\nin the esbuild metadata file. We are just appending this import\nstatement to the bottom of the file so that the sourcemaps are\nstill functional.\n\nThe end result is that the css for these dependencies will now be\nbundled into a single .css request for each dep / chunk that contains\nimports to a css file.","shortMessageHtmlLink":"feat(css): bundle css as part of optimizeDeps"}},{"before":"10effe19aa58820269d4eb5d95f91aab9450bbde","after":"7fb726c9a08826a2e66f62515053c16c38eb247c","ref":"refs/heads/feat/optimize-deps-css2","pushedAt":"2024-01-12T16:05:42.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"thebanjomatic","name":"Adam Hines","path":"/thebanjomatic","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/17907922?s=80&v=4"},"commit":{"message":"feat(css): bundle css as part of optimizeDeps\n\nThis feature is intended to support component libraries that ship tree-\nshakable modules that include css imports.\n\nWhen building with Vite, if the js files within your dependencies,\ncontain css, then at build time, the css will get pulled into the app's\ncss bundles and will be tree-shaken as part of the build (if\nsideEffects: false in the dependency and the module which imported the\ncss is also dropped). For dev builds, treeshaking doesn't happen, and\ninstead, all of the css will wind up getting imported. The current\nbehavior with optimizeDeps is that the css imports are externalized and\npreserved in the resulting .js deps bundles. This can result in a lot of\ncss request being made on page load to the dev server. While css imports\nare faster to process than js imports, it still isn't ideal.\n\nThis feature extends the default preoptimized dependency bundling to\nsupport css imports from within the dependency's .js files. Esbuild\nalready supports this feature, but it does so by bundling the css to a\nsingle .css bundle that sits alongside the js bundle, and it removes all\nimports to the css files from the resulting js bundle. The implied use-\ncase is that consumers of a library built with esbuild would need to use\na style tag, or import the css file directly.\n\nSince we can't really change the semantics of how the library is\nconsumed as a result of optimizeDeps, we need to inject a single import\nstatement into the .js bundle if it has a corresponding cssBundle file\nin the esbuild metadata file. We are just appending this import\nstatement to the bottom of the file so that the sourcemaps are\nstill functional.\n\nThe end result is that the css for these dependencies will now be\nbundled into a single .css request for each dep / chunk that contains\nimports to a css file.","shortMessageHtmlLink":"feat(css): bundle css as part of optimizeDeps"}},{"before":"0e058962d74c45f6dd0edc2e830b8d89ee40ed96","after":"10effe19aa58820269d4eb5d95f91aab9450bbde","ref":"refs/heads/feat/optimize-deps-css2","pushedAt":"2024-01-12T16:02:53.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"thebanjomatic","name":"Adam Hines","path":"/thebanjomatic","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/17907922?s=80&v=4"},"commit":{"message":"feat(css): bundle css as part of optimizeDeps\n\nThis feature is intended to support component libraries that ship tree-\nshakable modules that include css imports.\n\nWhen building with Vite, if the js files within your dependencies,\ncontain css, then at build time, the css will get pulled into the app's\ncss bundles and will be tree-shaken as part of the build (if\nsideEffects: false in the dependency and the module which imported the\ncss is also dropped). For dev builds, treeshaking doesn't happen, and\ninstead, all of the css will wind up getting imported. The current\nbehavior with optimizeDeps is that the css imports are externalized and\npreserved in the resulting .js deps bundles. This can result in a lot of\ncss request being made on page load to the dev server. While css imports\nare faster to process than js imports, it still isn't ideal.\n\nThis feature extends the default preoptimized dependency bundling to\nsupport css imports from within the dependency's .js files. Esbuild\nalready supports this feature, but it does so by bundling the css to a\nsingle .css bundle that sits alongside the js bundle, and it removes all\nimports to the css files from the resulting js bundle. The implied use-\ncase is that consumers of a library built with esbuild would need to use\na style tag, or import the css file directly.\n\nSince we can't really change the semantics of how the library is\nconsumed as a result of optimizeDeps, we need to inject a single import\nstatement into the .js bundle if it has a corresponding cssBundle file\nin the esbuild metadata file. We are just appending this import\nstatement to the bottom of the file so that the sourcemaps are\nstill functional.\n\nThe end result is that the css for these dependencies will now be\nbundled into a single .css request for each dep / chunk that contains\nimports to a css file.","shortMessageHtmlLink":"feat(css): bundle css as part of optimizeDeps"}},{"before":"53e6d5c77356e84e95888dc3515d72afb0588f7a","after":"0e058962d74c45f6dd0edc2e830b8d89ee40ed96","ref":"refs/heads/feat/optimize-deps-css2","pushedAt":"2024-01-12T16:01:11.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"thebanjomatic","name":"Adam Hines","path":"/thebanjomatic","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/17907922?s=80&v=4"},"commit":{"message":"feat(css): bundle css as part of optimizeDeps\n\nThis feature is intended to support component libraries that ship tree-\nshakable modules that include css imports.\n\nWhen building with Vite, if the js files within your dependencies,\ncontain css, then at build time, the css will get pulled into the app's\ncss bundles and will be tree-shaken as part of the build (if\nsideEffects: false in the dependency and the module which imported the\ncss is also dropped). For dev builds, treeshaking doesn't happen, and\ninstead, all of the css will wind up getting imported. The current\nbehavior with optimizeDeps is that the css imports are externalized and\npreserved in the resulting .js deps bundles. This can result in a lot of\ncss request being made on page load to the dev server. While css imports\nare faster to process than js imports, it still isn't ideal.\n\nThis feature extends the default preoptimized dependency bundling to\nsupport css imports from within the dependency's .js files. Esbuild\nalready supports this feature, but it does so by bundling the css to a\nsingle .css bundle that sits alongside the js bundle, and it removes all\nimports to the css files from the resulting js bundle. The implied use-\ncase is that consumers of a library built with esbuild would need to use\na style tag, or import the css file directly.\n\nSince we can't really change the semantics of how the library is\nconsumed as a result of optimizeDeps, we need to inject a single import\nstatement into the .js bundle if it has a corresponding cssBundle file\nin the esbuild metadata file. We are just appending this import\nstatement to the bottom of the file so that the sourcemaps are\nstill functional.\n\nThe end result is that the css for these dependencies will now be\nbundled into a single .css request for each dep / chunk that contains\nimports to a css file.","shortMessageHtmlLink":"feat(css): bundle css as part of optimizeDeps"}},{"before":"3fc22ba377003e108284d8d5bcf3714eeb5c9f1a","after":"53e6d5c77356e84e95888dc3515d72afb0588f7a","ref":"refs/heads/feat/optimize-deps-css2","pushedAt":"2024-01-12T15:49:37.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"thebanjomatic","name":"Adam Hines","path":"/thebanjomatic","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/17907922?s=80&v=4"},"commit":{"message":"feat(css): bundle css as part of optimizeDeps\n\nThis feature is intended to support component libraries that ship tree-\nshakable modules that include css imports.\n\nWhen building with Vite, if the js files within your dependencies,\ncontain css, then at build time, the css will get pulled into the app's\ncss bundles and will be tree-shaken as part of the build (if\nsideEffects: false in the dependency and the module which imported the\ncss is also dropped). For dev builds, treeshaking\ndoesn't happen, and instead, all of the css will wind up getting\nimported. The current behavior with optimizeDeps is that the css imports\nare externalized and preserved in the resulting .js deps bundles. This\ncan result in a lot of css request being made on page load to the dev\nserver. While css imports are faster to process than js imports, it\nstill isn't ideal.\n\nThis feature extends the default preoptimized dependency bundling to\nsupport css imports from within the dependency's .js files. Esbuild\nalready supports this feature, but it does so by bundling the css to a\nsingle .css bundle that sits alongside the js bundle, and it removes all\nimports to the css files from the resulting js bundle. The implied use-\ncase is that consumers of a library built with esbuild would need to use\na style tag, or import the css file directly.\n\nSince we can't really change the semantics of how the library is\nconsumed as a result of optimizeDeps, we need to inject a single import\nstatement into the .js bundle if it has a corresponding cssBundle file\nin the esbuild metadata file. We are just appending this import\nstatement to the bottom of the file so that the sourcemaps are\nstill functional.\n\nThe end result is that the css for these dependencies will now be\nbundled into a single .css request for each dep / chunk that contains\nimports to a css file.","shortMessageHtmlLink":"feat(css): bundle css as part of optimizeDeps"}},{"before":"185dbcb993c65c12e619a934f3e7f490b587c9aa","after":"3fc22ba377003e108284d8d5bcf3714eeb5c9f1a","ref":"refs/heads/feat/optimize-deps-css2","pushedAt":"2024-01-12T15:46:17.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"thebanjomatic","name":"Adam Hines","path":"/thebanjomatic","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/17907922?s=80&v=4"},"commit":{"message":"feat(css): bundle css as part of optimizeDeps\n\nThis feature is intended to support component libraries that ship tree-\nshakable modules that include css imports.\n\nWhen building with Vite, if the js files within your dependencies,\ncontain css, then at build time, the css will get pulled into the app's\ncss bundles and will be tree-shaken as part of the build (if\nsideEffects: false in the dependency and the module which imported the\ncss is also dropped). For dev builds, treeshaking\ndoesn't happen, and instead, all of the css will wind up getting\nimported. The current behavior with optimizeDeps is that the css imports\nare externalized and preserved in the resulting .js deps bundles. This\ncan result in a lot of css request being made on page load to the dev\nserver. While css imports are faster to process than js imports, it\nstill isn't ideal.\n\nThis feature extends the default preoptimized dependency bundling to\nsupport css imports from within the dependency's .js files. Esbuild\nalready supports this feature, but it does so by bundling the css to a\nsingle .css bundle that sits alongside the js bundle, and it removes all\nimports to the css files from the resulting js bundle. The implied use-\ncase is that consumers of a library built with esbuild would need to use\na style tag, or import the css file directly.\n\nSince we can't really change the semantics of how the library is\nconsumed as a result of optimizeDeps, we need to inject a single import\nstatement into the .js bundle if it has a corresponding cssBundle file\nin the esbuild metadata file. We are just appending this import\nstatement to the bottom of the file so that the sourcemaps are\nstill functional.\n\nThe end result is that the css for these dependencies will now be\nbundled into a single .css request for each dep / chunk that contains\nimports to a css file.","shortMessageHtmlLink":"feat(css): bundle css as part of optimizeDeps"}},{"before":"6c6cbea06211c3ccee21ac1fa843c4beea00ed23","after":"185dbcb993c65c12e619a934f3e7f490b587c9aa","ref":"refs/heads/feat/optimize-deps-css2","pushedAt":"2024-01-12T15:34:06.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"thebanjomatic","name":"Adam Hines","path":"/thebanjomatic","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/17907922?s=80&v=4"},"commit":{"message":"feat(css): bundle css as part of optimizeDeps\n\nThis feature is intended to support component libraries that ship tree-\nshakable modules that include css imports.\n\nWhen building with Vite, if the js files within your dependencies,\ncontain css, then at build time, the css will get pulled into the app's\ncss bundles and will be tree-shaken as part of the build (if\nsideEffects: false in the dependency and the module which imported the\ncss is also dropped). For dev builds, treeshaking\ndoesn't happen, and instead, all of the css will wind up getting\nimported. The current behavior with optimizeDeps is that the css imports\nare externalized and preserved in the resulting .js deps bundles. This\ncan result in a lot of css request being made on page load to the dev\nserver. While css imports are faster to process than js imports, it\nstill isn't ideal.\n\nThis feature extends the default preoptimized dependency bundling to\nsupport css imports from within the dependency's .js files. Esbuild\nalready supports this feature, but it does so by bundling the css to a\nsingle .css bundle that sits alongside the js bundle, and it removes all\nimports to the css files from the resulting js bundle. The implied use-\ncase is that consumers of a library built with esbuild would need to use\na style tag, or import the css file directly.\n\nSince we can't really change the semantics of how the library is\nconsumed as a result of optimizeDeps, we need to inject a single import\nstatement into the .js bundle if it has a corresponding cssBundle file\nin the esbuild metadata file. We are just appending this import\nstatement to the bottom of the file so that the sourcemaps are\nstill functional.\n\nThe end result is that the css for these dependencies will now be\nbundled into a single .css request for each dep / chunk that contains\nimports to a css file.","shortMessageHtmlLink":"feat(css): bundle css as part of optimizeDeps"}},{"before":"15428663037b1c86c9367b9b7a453c26ebb38e5c","after":"6c6cbea06211c3ccee21ac1fa843c4beea00ed23","ref":"refs/heads/feat/optimize-deps-css2","pushedAt":"2024-01-12T00:29:06.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"thebanjomatic","name":"Adam Hines","path":"/thebanjomatic","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/17907922?s=80&v=4"},"commit":{"message":"feat(css): bundle css as part of optimizeDeps\n\nThis feature is intended to support component libraries that ship tree-\nshakable modules that include css imports.\n\nWhen building with Vite, if the js files within your dependencies,\ncontain css, then at build time, the css will get pulled into the app's\ncss bundles and will be tree-shaken as part of the build (if\nsideEffects: false in the dependency and the module which imported the\ncss is also dropped). For dev builds, treeshaking\ndoesn't happen, and instead, all of the css will wind up getting\nimported. The current behavior with optimizeDeps is that the css imports\nare externalized and preserved in the resulting .js deps bundles. This\ncan result in a lot of css request being made on page load to the dev\nserver. While css imports are faster to process than js imports, it\nstill isn't ideal.\n\nThis feature extends the default preoptimized dependency bundling to\nsupport css imports from within the dependency's .js files. Esbuild\nalready supports this feature, but it does so by bundling the css to a\nsingle .css bundle that sits alongside the js bundle, and it removes all\nimports to the css files from the resulting js bundle. The implied use-\ncase is that consumers of a library built with esbuild would need to use\na style tag, or import the css file directly.\n\nSince we can't really change the semantics of how the library is\nconsumed as a result of optimizeDeps, we need to inject a single import\nstatement into the .js bundle if it has a corresponding cssBundle file\nin the esbuild metadata file. We are just appending this import\nstatement to the bottom of the file so that the sourcemaps are\nstill functional.\n\nThe end result is that the css for these dependencies will now be\nbundled into a single .css request for each dep / chunk that contains\nimports to a css file.","shortMessageHtmlLink":"feat(css): bundle css as part of optimizeDeps"}},{"before":"368012fc260c8bd25a2f15881406cdc0bf85896b","after":"15428663037b1c86c9367b9b7a453c26ebb38e5c","ref":"refs/heads/feat/optimize-deps-css2","pushedAt":"2024-01-12T00:26:43.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"thebanjomatic","name":"Adam Hines","path":"/thebanjomatic","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/17907922?s=80&v=4"},"commit":{"message":"feat(css): bundle css as part of optimizeDeps\n\nThis feature is intended to support component libraries that ship tree-\nshakable modules that include css imports.\n\nWhen building with Vite, if the js files within your dependencies,\ncontain css, then at build time, the css will get pulled into the app's\ncss bundles and will be tree-shaken as part of the build (if\nsideEffects: false in the dependency and the module which imported the\ncss is also dropped). For dev builds, treeshaking\ndoesn't happen, and instead, all of the css will wind up getting\nimported. The current behavior with optimizeDeps is that the css imports\nare externalized and preserved in the resulting .js deps bundles. This\ncan result in a lot of css request being made on page load to the dev\nserver. While css imports are faster to process than js imports, it\nstill isn't ideal.\n\nThis feature extends the default preoptimized dependency bundling to\nsupport css imports from within the dependency's .js files. Esbuild\nalready supports this feature, but it does so by bundling the css to a\nsingle .css bundle that sits alongside the js bundle, and it removes all\nimports to the css files from the resulting js bundle. The implied use-\ncase is that consumers of a library built with esbuild would need to use\na style tag, or import the css file directly.\n\nSince we can't really change the semantics of how the library is\nconsumed as a result of optimizeDeps, we need to inject a single import\nstatement into the .js bundle if it has a corresponding cssBundle file\nin the esbuild metadata file. We are just appending this import\nstatement to the bottom of the file so that the sourcemaps are\nstill functional.\n\nThe end result is that the css for these dependencies will now be\nbundled into a single .css request for each dep / chunk that contains\nimports to a css file.","shortMessageHtmlLink":"feat(css): bundle css as part of optimizeDeps"}},{"before":"941bb1610c9c9576e0b5738c9075b3eb2f16a357","after":"c643a8ae9d90691d60695c6de8d1d1f32e1ea045","ref":"refs/heads/main","pushedAt":"2024-01-12T00:20:10.000Z","pushType":"push","commitsCount":409,"pusher":{"login":"thebanjomatic","name":"Adam Hines","path":"/thebanjomatic","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/17907922?s=80&v=4"},"commit":{"message":"docs: add tip on browser extensions to perf guide (#15577)\n\nCo-authored-by: Bjorn Lu <bjornlu.dev@gmail.com>","shortMessageHtmlLink":"docs: add tip on browser extensions to perf guide (<a class=\"issue-link js-issue-link\" data-error-text=\"Failed to load title\" data-id=\"2076775021\" data-permission-text=\"Title is private\" data-url=\"https://github.com/vitejs/vite/issues/15577\" data-hovercard-type=\"pull_request\" data-hovercard-url=\"/vitejs/vite/pull/15577/hovercard\" href=\"https://github.com/vitejs/vite/pull/15577\">vitejs#15577</a>)"}},{"before":"19bcd70fc2066ea055df676d0e82adf0f5e43d76","after":"368012fc260c8bd25a2f15881406cdc0bf85896b","ref":"refs/heads/feat/optimize-deps-css2","pushedAt":"2023-09-28T14:53:56.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"thebanjomatic","name":"Adam Hines","path":"/thebanjomatic","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/17907922?s=80&v=4"},"commit":{"message":"chore: fixing typo in docs\n\nCo-authored-by: Brett Saunders <brett_saunders@btinternet.com>","shortMessageHtmlLink":"chore: fixing typo in docs"}},{"before":"bbfa5934d18944d8a34cf4fba1b57116fa402dc4","after":"19bcd70fc2066ea055df676d0e82adf0f5e43d76","ref":"refs/heads/feat/optimize-deps-css2","pushedAt":"2023-09-25T14:06:27.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"thebanjomatic","name":"Adam Hines","path":"/thebanjomatic","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/17907922?s=80&v=4"},"commit":{"message":"feat(css): bundle css as part of optimizeDeps\n\nThis feature is intended to support component libraries that ship tree-\nshakable modules that include css imports.\n\nWhen building with Vite, if the js files within your dependencies,\ncontain css, then at build time, the css will get pulled into the app's\ncss bundles and will be tree-shaken as part of the build (if\nsideEffects: false in the dependency and the module which imported the\ncss is also dropped). For dev builds, treeshaking\ndoesn't happen, and instead, all of the css will wind up getting\nimported. The current behavior with optimizeDeps is that the css imports\nare externalized and preserved in the resulting .js deps bundles. This\ncan result in a lot of css request being made on page load to the dev\nserver. While css imports are faster to process than js imports, it\nstill isn't ideal.\n\nThis feature extends the default preoptimized dependency bundling to\nsupport css imports from within the dependency's .js files. Esbuild\nalready supports this feature, but it does so by bundling the css to a\nsingle .css bundle that sits alongside the js bundle, and it removes all\nimports to the css files from the resulting js bundle. The implied use-\ncase is that consumers of a library built with esbuild would need to use\na style tag, or import the css file directly.\n\nSince we can't really change the semantics of how the library is\nconsumed as a result of optimizeDeps, we need to inject a single import\nstatement into the .js bundle if it has a corresponding cssBundle file\nin the esbuild metadata file. We are just appending this import\nstatement to the bottom of the file so that the sourcemaps are\nstill functional.\n\nThe end result is that the css for these dependencies will now be\nbundled into a single .css request for each dep / chunk that contains\nimports to a css file.","shortMessageHtmlLink":"feat(css): bundle css as part of optimizeDeps"}},{"before":null,"after":"bbfa5934d18944d8a34cf4fba1b57116fa402dc4","ref":"refs/heads/feat/optimize-deps-css2","pushedAt":"2023-09-25T14:05:34.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"thebanjomatic","name":"Adam Hines","path":"/thebanjomatic","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/17907922?s=80&v=4"},"commit":{"message":"feat(css): bundle css as part of optimizeDeps\n\nThis feature is intended to support component libraries that ship tree-\nshakable modules that include css imports.\n\nWhen building with Vite, if the js files within your dependencies,\ncontain css, then at build time, the css will get pulled into the app's\ncss bundles and will be tree-shaken as part of the build (if\nsideEffects: false in the dependency and the module which imported the\ncss is also dropped). For dev builds, treeshaking\ndoesn't happen, and instead, all of the css will wind up getting\nimported. The current behavior with optimizeDeps is that the css imports\nare externalized and preserved in the resulting .js deps bundles. This\ncan result in a lot of css request being made on page load to the dev\nserver. While css imports are faster to process than js imports, it\nstill isn't ideal.\n\nThis feature extends the default preoptimized dependency bundling to\nsupport css imports from within the dependency's .js files. Esbuild\nalready supports this feature, but it does so by bundling the css to a\nsingle .css bundle that sits alongside the js bundle, and it removes all\nimports to the css files from the resulting js bundle. The implied use-\ncase is that consumers of a library built with esbuild would need to use\na style tag, or import the css file directly.\n\nSince we can't really change the semantics of how the library is\nconsumed as a result of optimizeDeps, we need to inject a single import\nstatement into the .js bundle if it has a corresponding cssBundle file\nin the esbuild metadata file. We are just appending this import\nstatement to the bottom of the file so that the sourcemaps are\nstill functional.\n\nThe end result is that the css for these dependencies will now be\nbundled into a single .css request for each dep / chunk that contains\nimports to a css file.","shortMessageHtmlLink":"feat(css): bundle css as part of optimizeDeps"}}],"hasNextPage":true,"hasPreviousPage":false,"activityType":"all","actor":null,"timePeriod":"all","sort":"DESC","perPage":30,"cursor":"djE6ks8AAAAEPM8XXAA","startCursor":null,"endCursor":null}},"title":"Activity · thebanjomatic/vite"}