vtex
Add more configuration options to faststore.config.js
We are setting up Sentry for error logging on JW Pepper and their plugin requires adding config to the Next and adding some custom files to the project root.
I'm open to ideas on improvements or different ways of going about this.
The latest updates on your projects. Learn more about Vercel for Git ↗︎
| Name | Status | Preview | Comments | Updated (UTC) |
|---|---|---|---|---|
| faststore-site | ✅ Ready (Inspect) | Visit Preview | 💬 Add feedback | Jan 22, 2024 8:57pm |
![vercel[bot] avatar](https://avatars.githubusercontent.com/in/8329?v=4 "Published by a pub.dev verified publisher"){kind=small}
This pull request is automatically built and testable in CodeSandbox.
To see build info of the built libraries, click here or the icon next to each commit SHA.
Latest deployment of this branch, based on commit bd4b811d90b16e0c326fa74381e3d1dba17c578a:
| Sandbox | Source |
|---|---|
| Store UI Typescript | Configuration |
![codesandbox-ci[bot] avatar](https://avatars.githubusercontent.com/in/38409?v=4 "Published by a pub.dev verified publisher"){kind=small}
hey @jonmast Sorry for the delayed response! 🙇♀️
Firstly, thank you for your contribution!
We have some concerns about the potential overriding of previously set configurations in the next.config, which could affect certain features, such as the outputFileTracingRoot option. 🤔
Maybe we could explore an approach that allows modifying a specific set of parameters or something more controlled solution(?). This could help mitigate the risk of unintended consequences. I'll also bring this up for further discussion with the team.
@hellofanny Thanks for reviewing. Sentry needs access to the config to add a webpack plugin which is pretty involved in itself, so I'm not sure if restricting to just that key would really help?
It's pretty common for NextJS plugins to be exposed as a function which transforms the the config from what I've seen, and they attempt to update in a safe way which is compatible with any options being set. Obviously if you expose this config option there's no way to ensure it is only used by well behaved plugins though, so I understand your concern.
Ultimately I think if your users break things by overriding configs then that isn't your fault. Our alternative at this point is using custom versions of the FastStore packages which I'm sure is going to cause even more problems.