{"payload":{"feedbackUrl":"https://github.com/orgs/community/discussions/53140","repo":{"id":630197170,"defaultBranch":"main","name":"esbuild-sass-plugin","ownerLogin":"wfleming","currentUserCanPush":false,"isFork":true,"isEmpty":false,"createdAt":"2023-04-19T21:54:14.000Z","ownerAvatar":"https://avatars.githubusercontent.com/u/188402?v=4","public":true,"private":false,"isOrgOwned":false},"refInfo":{"name":"","listCacheKey":"v0:1684417496.587371","currentOid":""},"activityList":{"items":[{"before":"e6992c715618c679a3f2656afb639e16e9cc582f","after":"c1f301f0923b5afb01139a3f50049f20e273ccd7","ref":"refs/heads/main","pushedAt":"2023-12-12T19:41:07.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"wfleming","name":"Will Fleming","path":"/wfleming","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/188402?s=80&v=4"},"commit":{"message":"Bump for esbuild 0.19.0 compat","shortMessageHtmlLink":"Bump for esbuild 0.19.0 compat"}},{"before":"c079a1d8621fd6d2374fa544be6c9093a4b4487c","after":"e6992c715618c679a3f2656afb639e16e9cc582f","ref":"refs/heads/main","pushedAt":"2023-12-12T19:34:07.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"wfleming","name":"Will Fleming","path":"/wfleming","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/188402?s=80&v=4"},"commit":{"message":"Bump for esbuild 0.19.0 compat","shortMessageHtmlLink":"Bump for esbuild 0.19.0 compat"}},{"before":"478c49f862a476586735e00b20c1c00923adc39c","after":"c079a1d8621fd6d2374fa544be6c9093a4b4487c","ref":"refs/heads/main","pushedAt":"2023-06-13T17:39:12.182Z","pushType":"push","commitsCount":1,"pusher":{"login":"wfleming","name":"Will Fleming","path":"/wfleming","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/188402?s=80&v=4"},"commit":{"message":"2.11.0 - mark compatible with esbuild 0.18\n\nthe backwards incompat changes in 0.18 don't seem relevant","shortMessageHtmlLink":"2.11.0 - mark compatible with esbuild 0.18"}},{"before":"a48f664dfcc191c87182f35b20564a6c607c992c","after":"478c49f862a476586735e00b20c1c00923adc39c","ref":"refs/heads/main","pushedAt":"2023-06-13T16:57:23.380Z","pushType":"push","commitsCount":1,"pusher":{"login":"wfleming","name":"Will Fleming","path":"/wfleming","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/188402?s=80&v=4"},"commit":{"message":"README: a few updates\n\nClarify this is a fork, make install instructions reflect the fork\npackage name.","shortMessageHtmlLink":"README: a few updates"}},{"before":"4300fdddaa705c54cc8b3aae80bf8343551074ca","after":"a48f664dfcc191c87182f35b20564a6c607c992c","ref":"refs/heads/main","pushedAt":"2023-06-13T16:32:28.514Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"wfleming","name":"Will Fleming","path":"/wfleming","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/188402?s=80&v=4"},"commit":{"message":"update package name, version 2.10.0\n\nI'll be publishing this as a separate package, see https://github.com/glromeo/esbuild-sass-plugin/issues/137","shortMessageHtmlLink":"update package name, version 2.10.0"}},{"before":"bf97dd1de0d6df0052dd1bfee4bce4c3e1703ba5","after":"4300fdddaa705c54cc8b3aae80bf8343551074ca","ref":"refs/heads/main","pushedAt":"2023-06-13T16:31:05.846Z","pushType":"push","commitsCount":1,"pusher":{"login":"wfleming","name":"Will Fleming","path":"/wfleming","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/188402?s=80&v=4"},"commit":{"message":"version 2.10.0","shortMessageHtmlLink":"version 2.10.0"}},{"before":"f2e99b0522c97802bb64dad4865500787975fc8f","after":"bf97dd1de0d6df0052dd1bfee4bce4c3e1703ba5","ref":"refs/heads/main","pushedAt":"2023-06-13T16:29:32.419Z","pushType":"push","commitsCount":8,"pusher":{"login":"wfleming","name":"Will Fleming","path":"/wfleming","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/188402?s=80&v=4"},"commit":{"message":"Switch to sass-embedded\n\nHunting down some more reading on sass perf, I found this gh issue:\nhttps://github.com/sass/dart-sass/issues/868. That led to me looking at\nsass-embedded as a drop-in replacement for sass. I tried that, and yep,\nit does what it says on the tin. Works the same, but async is way faster\nand comparable to sync perf (with the benefit of much higher throughput\nif you're doing a lot of stuff concurrently). My entire build wall-clock\ntime is now down to 8s, and the slowest css bundles are 4.5s.\n\nBiggest downside seems to be that dart isn't compatible with musl libc,\nso I had to swap the base docker image I was using for my esbuild\npipeline. Unclear to me if there are other tradeoffs.","shortMessageHtmlLink":"Switch to sass-embedded"}},{"before":"8095df01de37ffc87bf5be2e6dfcab94522dc469","after":"1a4e17b6c0d9ebda3751ece396bbe1a9b43e9ffc","ref":"refs/heads/render-async","pushedAt":"2023-05-18T14:59:34.393Z","pushType":"push","commitsCount":1,"pusher":{"login":"wfleming","name":"Will Fleming","path":"/wfleming","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/188402?s=80&v=4"},"commit":{"message":"Switch to sass-embedded\n\nHunting down some more reading on sass perf, I found this gh issue:\nhttps://github.com/sass/dart-sass/issues/868. That led to me looking at\nsass-embedded as a drop-in replacement for sass. I tried that, and yep,\nit does what it says on the tin. Works the same, but async is way faster\nand comparable to sync perf (with the benefit of much higher throughput\nif you're doing a lot of stuff concurrently). My entire build wall-clock\ntime is now down to 8s, and the slowest css bundles are 4.5s.\n\nBiggest downside seems to be that dart isn't compatible with musl libc,\nso I had to swap the base docker image I was using for my esbuild\npipeline. Unclear to me if there are other tradeoffs.","shortMessageHtmlLink":"Switch to sass-embedded"}},{"before":"2059573dd9af5fd2c4ce685780f4087bc45854ba","after":"8095df01de37ffc87bf5be2e6dfcab94522dc469","ref":"refs/heads/render-async","pushedAt":"2023-05-18T13:59:30.155Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"wfleming","name":"Will Fleming","path":"/wfleming","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/188402?s=80&v=4"},"commit":{"message":"spike: async rendering\n\nwe have a lot of entrypoints/css bundles in our app, and in adding them\nall I realized the build was getting a lot slower and, suspiciously, all\nthe sass builds took the exact same amount of time to build. Seemed like\na symptom using sync interfaces could cause, so I thought I'd try seeing\nif async helped.\n\nIt did not! [Dart's docs][0] do say upfront that the async interface can\nbe ~2x slower, but I hoped that there'd still be a win on overall\nthroughput even if individual bundles were slower. For some bundles that\nwas the case: previously every css bundle was about ~8.6s, some smaller\nones are now ~500ms. However, the slow ones got a lot more than 2x\nslower: a few are now ~18.5s, which is longer than the previous entire\nbuild (including JS), so overall wall-clock time of my entire build went\nup from ~11s to ~20s.\n\nSo this went nowhere. It's possible there's still some synchronous\nchokepoints in the plugin I didn't see, but I'm out of time on this\nright now. If this had been more promising I would have put in more work\nto make it an option for the plugin. Committing it anyway as a\nhistorical artifact. libsass's poor async performance seems like it must\nbe a design issue of some kind, so maybe they'll improve that in the\nfuture.\n\n[0]: https://sass-lang.com/documentation/js-api/modules#compileStringAsync","shortMessageHtmlLink":"spike: async rendering"}},{"before":null,"after":"2059573dd9af5fd2c4ce685780f4087bc45854ba","ref":"refs/heads/render-async","pushedAt":"2023-05-18T13:44:56.587Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"wfleming","name":"Will Fleming","path":"/wfleming","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/188402?s=80&v=4"},"commit":{"message":"spike: async rendering\n\nwe have a lot of entrypoints/css bundles in our app, and in adding them\nall I realized the build was getting a lot slower and, suspiciously, all\nthe sass builds took the exact same amount of time to build. Seemed like\na symptom using sync interfaces could cause, so I thought I'd try seeing\nif async helped.\n\nIt did not! [Dart's docs][0] do say upfront that the async interface can\nbe ~2x slower, but I hoped that there'd still be a win on overall\nthroughput even if individual bundles were slower. For some bundles that\nwas the case: previously every css bundle was about ~8.6s, some smaller\nones are now ~3.0s. However, the slow ones got a lot more than 2x\nslower: a few are now ~22.8s, which is longer than the previous entire\nbuild (including JS).\n\nSo this went nowhere. If it had been helpful I would have put in more\nwork to make it an option for the plugin. Committing it anyway as a\nhistorical artifact. libsass's poor async performance seems like it must\nbe a design issue of some kind, so maybe they'll improve that in the\nfuture.\n\n[0]: https://sass-lang.com/documentation/js-api/modules#compileStringAsync","shortMessageHtmlLink":"spike: async rendering"}},{"before":"b43c7f9d0fe0fee594d4cfdcce01182d679a2b32","after":"c7fbd0d4dabd8bd99c2c5f9a101bc66ba09921b1","ref":"refs/heads/esbuild-warnings","pushedAt":"2023-04-20T13:06:02.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"wfleming","name":"Will Fleming","path":"/wfleming","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/188402?s=80&v=4"},"commit":{"message":"Capture sass warnings, emit them as esbuild warnings\n\nSass just logs warnings as they occur. This is a bit of a sub-par\nexperience with esbuild, and it would be nicer if the warnings were\nemitted by esbuild as it does other warnings/errors.\n\nThere is some awkwardness to capturing the warnings: sass's API seems a\nbit stuck in some pre-async design patterns, and having a separate\nlogger that gets called with syntax warnings rather than returning them\nas part of the compile result is one symptom of that.\n\nAccomplishing this with config outside the plugin is feasible but\nannoying. It requires writing a wrapper plugin around `sassPlugin` that\nwraps the `onLoad` handler to append captured warnings, plus an\n`onStart` handler to clear warnings (for watch mode). Additionally, if\nthe build config has multiple entrypoints it's impossible to tell which\nfile a warning in an entrypoint came from: warnings directly within an\nentrypoint don't have a `url` on the warning message (since this plugin\nreads the file and passes the contents to `sass.renderString`).\nImplemented within the plugin's renderer, this can be worked around\neasily since there's only ever one entrypoint in scope.\n\nSo I think the cleanest way to capture this data is to construct the\nlogger & store the warnings as close to the `sass.renderString` call as\nreasonable. My hope is others will also see this as a useful default\nbehavior!","shortMessageHtmlLink":"Capture sass warnings, emit them as esbuild warnings"}},{"before":"51b854580befd7e7ed122925c47bff42382ff382","after":"b43c7f9d0fe0fee594d4cfdcce01182d679a2b32","ref":"refs/heads/esbuild-warnings","pushedAt":"2023-04-20T13:02:53.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"wfleming","name":"Will Fleming","path":"/wfleming","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/188402?s=80&v=4"},"commit":{"message":"Capture sass warnings, emit them as esbuild warnings\n\nSass just logs warnings as they occur. This is a bit of a sub-par\nexperience with esbuild, and it would be nicer if the warnings were\nemitted by esbuild as it does other warnings/errors.\n\nThere is some awkwardness to capturing the warnings: sass's API seems a\nbit stuck in some pre-async design patterns, and having a separate\nlogger that gets called with syntax warnings rather than returning them\nas part of the compile result is one symptom of that.\n\nAccomplishing this with config outside the plugin is feasible but\nannoying. It requires writing a wrapper plugin around `sassPlugin` that\nwraps the `onLoad` handler to append captured warnings, plus an\n`onStart` handler to clear warnings (for watch mode). Additionally, if\nthe build config has multiple entrypoints it's impossible to tell which\nfile a warning in an entrypoint came from: warnings directly within an\nentrypoint don't have a `url` on the warning message (since this plugin\nreads the file and passes the contents to `sass.renderString`).\nImplemented within the plugin's renderer, this can be worked around\neasily since there's only ever one entrypoint in scope.\n\nSo I think the cleanest way to capture this data is to construct the\nlogger & store the warnings as close to the `sass.renderString` call as\nreasonable. My hope is others will also see this as a useful default\nbehavior!","shortMessageHtmlLink":"Capture sass warnings, emit them as esbuild warnings"}},{"before":"dcf748bd3cd21beb3c6c87c98699f0adfa97a365","after":"51b854580befd7e7ed122925c47bff42382ff382","ref":"refs/heads/esbuild-warnings","pushedAt":"2023-04-20T12:37:27.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"wfleming","name":"Will Fleming","path":"/wfleming","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/188402?s=80&v=4"},"commit":{"message":"Capture sass warnings, emit them as esbuild warnings\n\nSass just logs warnings as they occur. This is a bit of a sub-par\nexperience with esbuild, and it would be nicer if the warnings were\nemitted by esbuild as it does other warnings/errors.\n\nThere is some awkwardness to capturing the warnings: sass's API seems a\nbit stuck in some pre-async design patterns, and having a separate\nlogger that gets called with syntax warnings rather than returning them\nas part of the compile result is one symptom of that.\n\nAccomplishing this with config outside the plugin is feasible but\nannoying. It requires writing a wrapper plugin around `sassPlugin` that\nwraps the `onLoad` handler to append captured warnings, plus an\n`onStart` handler to clear warnings (for watch mode). Additionally, if\nthe build config has multiple entrypoints it's impossible to tell which\nfile a warning in an entrypoint came from: warnings directly within an\nentrypoint don't have a `url` on the warning message (since this plugin\nreads the file and passes the contents to `sass.renderString`).\nImplemented within the plugin's renderer, this can be worked around\neasily since there's only ever one entrypoint in scope.\n\nSo I think the cleanest way to capture this data is to construct the\nlogger & store the warnings as close to the `sass.renderString` call as\nreasonable. My hope is others will also see this as a useful default\nbehavior!","shortMessageHtmlLink":"Capture sass warnings, emit them as esbuild warnings"}},{"before":"8da47bb851fb13b882276ae82504213055ded6f7","after":"dcf748bd3cd21beb3c6c87c98699f0adfa97a365","ref":"refs/heads/esbuild-warnings","pushedAt":"2023-04-20T01:02:15.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"wfleming","name":"Will Fleming","path":"/wfleming","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/188402?s=80&v=4"},"commit":{"message":"Capture sass warnings, emit them as esbuild warnings\n\nSass just logs warnings as they occur. This is a bit of a sub-par\nexperience with esbuild, and it would be nicer if the warnings were\nemitted by esbuild as it does other warnings/errors.\n\nThere is some awkwardness to capturing the warnings: sass's API seems a\nbit stuck in some pre-async design patterns, and having a separate\nlogger that gets called with syntax warnings rather than returning them\nas part of the compile result is one symptom of that.\n\nBecause of that, injecting a logger as part of the initial options\npassed to this plugin is a workable solution, but a bit of a chore: you\nalso need an `onStart` plugin or similar to clear warnings in watch mode\nbetween builds.\n\nSo I think the cleanest way to capture this data is to construct the\nlogger & store the warnings as close to the `sass.renderString` call as\nreasonable. My hope is others will also see this as a useful default\nbehavior!","shortMessageHtmlLink":"Capture sass warnings, emit them as esbuild warnings"}},{"before":"e3b780f8d43db1c7de1cfee969d6c289f05c6dee","after":"8da47bb851fb13b882276ae82504213055ded6f7","ref":"refs/heads/esbuild-warnings","pushedAt":"2023-04-20T00:55:04.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"wfleming","name":"Will Fleming","path":"/wfleming","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/188402?s=80&v=4"},"commit":{"message":"Capture sass warnings, emit them as esbuild warnings\n\nSass just logs warnings as they occur. This is a bit of a sub-par\nexperience with esbuild, and it would be nicer if the warnings were\nemitted by esbuild as it does other warnings/errors.\n\nThere is some awkwardness to capturing the warnings: sass's API seems a\nbit stuck in some pre-async design patterns, and having a separate\nlogger that gets called with syntax warnings rather than returning them\nas part of the compile result is one symptom of that.\n\nBecause of that, injecting a logger as part of the initial options\npassed to this plugin is a workable solution, but a bit of a chore: you\nalso need an `onStart` plugin or similar to clear warnings in watch mode\nbetween builds.\n\nSo I think the cleanest way to capture this data is to construct the\nlogger & store the warnings as close to the `sass.renderString` call as\nreasonable. My hope is others will also see this as a useful default\nbehavior!","shortMessageHtmlLink":"Capture sass warnings, emit them as esbuild warnings"}},{"before":"b8f130dd434f4157641846ad0c47ef1032defbed","after":"e3b780f8d43db1c7de1cfee969d6c289f05c6dee","ref":"refs/heads/esbuild-warnings","pushedAt":"2023-04-19T22:18:22.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"wfleming","name":"Will Fleming","path":"/wfleming","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/188402?s=80&v=4"},"commit":{"message":"Capture sass warnings, emit them as esbuild warnings\n\nSass just logs warnings as they occur. This is a bit of a sub-par\nexperience with esbuild, and it would be nicer if the warnings were\nemitted by esbuild as it does other warnings/errors.\n\nThere is some awkwardness to capturing the warnings: sass's API seems a\nbit stuck in some pre-async design patterns, and having a separate\nlogger that gets called with syntax warnings rather than returning them\nas part of the compile result is one symptom of that.\n\nBecause of that, injecting a logger as part of the initial options\npassed to this plugin is tricky because in watch mode you also need to\nworry about clearing out those errors when the build restarts, and this\ngets a bit worse if you're bundling a lot of different sass entrypoints.\n\nSo I think the cleanest way to capture this data is to construct the\nlogger & store the warnings as close to the `sass.renderString` call as\nreasonable. My hope is others will also see this as an improvement on\nthe current behavior, but this config will continue to use the\nconfigured logger if one is already specified in the options.","shortMessageHtmlLink":"Capture sass warnings, emit them as esbuild warnings"}},{"before":"bea4645fccb0c56d6ec39286d3ea077161f515d0","after":"b8f130dd434f4157641846ad0c47ef1032defbed","ref":"refs/heads/esbuild-warnings","pushedAt":"2023-04-19T22:18:10.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"wfleming","name":"Will Fleming","path":"/wfleming","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/188402?s=80&v=4"},"commit":{"message":"Capture sass warnings, emit them as esbuild warnings\n\nSass just logs warnings as they occur. This is a bit of a sub-par\nexperience with esbuild, and it would be nicer if the warnings were\nemitted by esbuild as it does other warnings/errors.\n\nThere is some awkwardness to capturing the warnings: sass's API seems a\nbit stuck in some pre-async design patterns, and having a separate\nlogger that gets called with syntax warnings rather than returning them\nas part of the compile result is one symptom of that.\n\nBecause of that, injecting a logger as part of the initial options\npassed to this plugin is tricky because in watch mode you also need to\nworry about clearing out those errors when the build restarts, and this\ngets a bit worse if you're bundling a lot of different sass entrypoints.\n\nSo I think the cleanest way to capture this data is to construct the\nlogger & store the warnings as close to the `sass.renderString` call as\nreasonable. My hope is others will also see this as an improvement on\nthe current behavior, but this config will continue to use the\nconfigured logger if one is already specified in the options.","shortMessageHtmlLink":"Capture sass warnings, emit them as esbuild warnings"}},{"before":"981c1d7644621ce869c2843745e49844d590ebbe","after":"bea4645fccb0c56d6ec39286d3ea077161f515d0","ref":"refs/heads/esbuild-warnings","pushedAt":"2023-04-19T22:14:47.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"wfleming","name":"Will Fleming","path":"/wfleming","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/188402?s=80&v=4"},"commit":{"message":"Capture sass warnings, emit them as esbuild warnings\n\nSass just logs warnings as they occur. This is a bit of a sub-par\nexperience with esbuild, and it would be nicer if the warnings were\nemitted by esbuild as it does other warnings/errors.\n\nThere is some awkwardness to capturing the warnings: sass's API seems a\nbit stuck in some pre-async design patterns, and having a separate\nlogger that gets called with syntax warnings rather than returning them\nas part of the compile result is one symptom of that.\n\nBecause of that, injecting a logger as part of the initial options\npassed to this plugin is tricky because in watch mode you also need to\nworry about clearing out those errors when the build restarts, and this\ngets a bit worse if you're bundling a lot of different sass entrypoints.\n\nSo I think the cleanest way to capture this data is to construct the\nlogger & store the warnings as close to the `sass.renderString` call as\nreasonable. My hope is others will also see this as an improvement on\nthe current behavior, but this config will continue to use the\nconfigured logger if one is already specified in the options.","shortMessageHtmlLink":"Capture sass warnings, emit them as esbuild warnings"}},{"before":null,"after":"981c1d7644621ce869c2843745e49844d590ebbe","ref":"refs/heads/esbuild-warnings","pushedAt":"2023-04-19T22:13:43.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"wfleming","name":"Will Fleming","path":"/wfleming","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/188402?s=80&v=4"},"commit":{"message":"Capture sass warnings, emit them as esbuild warnings\n\nSass just logs warnings as they occur. This is a bit of a sub-par\nexperience with esbuild, and it would be nicer if the warnings were\nemitted by esbuild as it does other warnings/errors.\n\nThere is some awkardness to capturing the warnings: sass's API seems a\nbit stuck in some pre-async design patterns, and having a separate\nlogger that gets called with syntax warnings rather than returning them\nas part of the compile result is one symptom of that.\n\nBecause of that, injecting a logger as part of the initial options\npassed to this plugin is tricky because in watch mode you also need to\nworry about clearing out those errors when the build restarts, and this\ngets a bit worse if you're bundling a lot of different sass entrypoints.\n\nSo I think the cleanest way to capture this data is to construct the\nlogger & store the warnings as close to the `sass.renderString` call as\nreasonable. My hope is others will also see this as an improvement on\nthe current behavior, but this config will continue to use the\nconfigured logger if one is already specified in the options.","shortMessageHtmlLink":"Capture sass warnings, emit them as esbuild warnings"}}],"hasNextPage":false,"hasPreviousPage":false,"activityType":"all","actor":null,"timePeriod":"all","sort":"DESC","perPage":30,"cursor":"djE6ks8AAAADyLkkFwA","startCursor":null,"endCursor":null}},"title":"Activity · wfleming/esbuild-sass-plugin"}