noahdarveau/size-limit test #2717
Conversation
size-limit report 📦
|
package.json
Outdated
| "brotli": false, | ||
| "path": "./packages/teams-js/dist/esm/packages/teams-js/src/index.js", | ||
| "import": "{ app, authentication, pages }", | ||
| "limit": "58.033 KB" |
There was a problem hiding this comment.
That is something we could do. I ran into a bit of a problem trying to figure out how much wiggle room we should allow, that would both allow for refactoring and small changes but still catch treeshaking breakages.
|
What will the developer experience be like when someone makes a change that exceeds the limit? |
If a developer makes a change that causes the size limit to be exceeded, their build will fail with it throwing an error that the size limit has been increased. It will then be up to the developer to determine if this is a warranted size increase, and either increase the size limit accordingly or resolve the cause of the size increase. |
Do we have any control over what the message says? E.g., how will the developer know where to update the size? How will the developer know what to consider when deciding whether they've "broken" tree shaking? At the very least can we put a comment near the size definition to say "Hey if you are changing this you better be sure you didn't break tree shaking; don't just update this because your build failed. Here's a link that describes tree shaking and how you can know whether you broke it: etc. etc." |
…/microsoft-teams-library-js into noahdarveau/size-limit
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Added a configuration to size-limit that will build with
app,authentication, andpages. The size limit threshold is set to the size of these capabilities. If any of the other capabilities stop treeshaking, then the size of the build will increase above this threshold and fail the build. However, if someone is making changes toapp,authentication, orpages, then they will need to adjust the size limit threshold accordingly. The size-limit step runs as part of the build step, so if there is a size issue, it will fail at build time.