vitest-dev
docs: update error.ts for inlining a package
Description
Update recommended workaround for inlining a package that has a syntax error when resolving a bundled dependency, since the current workaround uses deprecated config options
close vitest-dev#6237
Please don't delete this checklist! Before submitting the PR, please make sure you do the following:
- [x] It's really useful if your PR references an issue where it is discussed ahead of time. If the feature is substantial or introduces breaking changes without a discussion, PR might be closed.
- [x] Ideally, include a test that fails without this PR but passes with it.
- [x] Please, don't make changes to
pnpm-lock.yamlunless you introduce a new test example.
Tests
- [x] Run the tests with
pnpm test:ci.
Documentation
- [x] If you introduce new functionality, document it. You can run documentation with
pnpm run docscommand.
Changesets
- [x] Changes in changelog are generated from PR name. Please, make sure that it explains your changes in an understandable manner. Please, prefix changeset messages with
feat:,fix:,perf:,docs:, orchore:.
Deploy Preview for vitest-dev ready!
Built without sensitive environment variables
| Name | Link |
|---|---|
| Latest commit | 857b82d2a64b73677281ea2293d4485276428912 |
| Latest deploy log | https://app.netlify.com/sites/vitest-dev/deploys/66a71e32cee2ea000839dc07 |
| Deploy Preview | https://deploy-preview-6238--vitest-dev.netlify.app |
| Preview on mobile | Toggle QR Code...Use your smartphone camera to open QR code link. |
To edit notification comments on pull requests, go to your Netlify site configuration.
![netlify[bot] avatar](https://avatars.githubusercontent.com/in/13473?v=4 "Published by a pub.dev verified publisher"){kind=small}
server.deps.inline is not deprecated, deps.inline is
Using optimizer actually won't do anything unless it's enabled
Oh I see. I believe my particular use case was alias configuration in a bundled dependency, which didn't work with the recommended solution. Would it be worth extending the error then instead of replacing it?
Oh I see. I believe my particular use case was alias configuration in a bundled dependency, which didn't work with the recommended solution. Would it be worth extending the error then instead of replacing it?
How exactly do you want to extend it?