feat: add support for custom unenv preset path #7522
Conversation
Introduce `WRANGLER_UNENV_PRESET_PATH` to specify a custom root path for the unenv preset.
🦋 Changeset detectedLatest commit: 5a39e9e The changes in this PR will be included in the next version bump. This PR includes changesets to release 2 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
A wrangler prerelease is available for testing. You can install this latest build in your project with: npm install --save-dev https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/12279501204/npm-package-wrangler-7522You can reference the automatically updated head of this PR with: npm install --save-dev https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/prs/7522/npm-package-wrangler-7522Or you can use npx https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/12279501204/npm-package-wrangler-7522 dev path/to/script.jsAdditional artifacts:npx https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/12279501204/npm-package-create-cloudflare-7522 --no-auto-updatenpm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/12279501204/npm-package-cloudflare-kv-asset-handler-7522npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/12279501204/npm-package-miniflare-7522npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/12279501204/npm-package-cloudflare-pages-shared-7522npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/12279501204/npm-package-cloudflare-vitest-pool-workers-7522npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/12279501204/npm-package-cloudflare-workers-editor-shared-7522npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/12279501204/npm-package-cloudflare-workers-shared-7522npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/12279501204/npm-package-cloudflare-workflows-shared-7522Note that these links will no longer work once the GitHub Actions artifact expires.
Please ensure constraints are pinned, and |
| ) { | ||
| // esbuild expects alias paths to be absolute | ||
| const aliasAbsolute: Record<string, string> = {}; | ||
| for (const [module, unresolvedAlias] of Object.entries(alias)) { | ||
| try { | ||
| const paths = unenvPresetPath ? [unenvPresetPath] : undefined; |
There was a problem hiding this comment.
Can we just call
const unenvPresetPath = getUnenvPresetPathFromEnv();
here and avoid having to thread it through the code?
There was a problem hiding this comment.
My thinking was that ultimately we want the plugin to live in the preset package.
WDYT?
There was a problem hiding this comment.
(quick call with Vic, we might eventually move the plugin to unenv core as part of unjs/unenv#263 -- this unifies impl between nitro and wrangler as a bonus) + working on a quick feature in unenv to support alias resolution.
There was a problem hiding this comment.
Not sure I follow here.
If we move this to the preset (or even to unenv core) then this unenvPresetPath would be moot, right? So we'd need to redo this code then anyway.
In that case just loading the env var where it is needed is simplest and touches the least code.
There was a problem hiding this comment.
So there are two things:
- To move wrangler PRs forward add a feature to unenv core to allow full path resolves
- In the future, to move the plugin stuff as an unplugin
There was a problem hiding this comment.
Does that affect my original comment to move the reading of the environment variable into this code?
There was a problem hiding this comment.
If we move this to the preset (or even to unenv core) then this unenvPresetPath would be moot, right?
It would only be a different path but same code.
In that case just loading the env var where it is needed is simplest and touches the least code.
Does that affect my original comment to move the reading of the environment variable into this code?
In general I find injecting values cleaner.
i.e. in this case if we have an hardcoded WRANGLER_... name, we would have to change that if we move the plugin. Injecting the value is more flexible (i.e. the first point above).
There was a problem hiding this comment.
Oh sorry, if you meant to just move it out yes it makes sense.
(my point was that, we are moving resolution logic out shortly after unjs/unenv#372 lands!)
We are moving the unenv preset to this repo.
We will need to be able to test the version that is package with wrangler as well as the dev version. We can do that by passing the path to the dev version in the added env var.
/cc @pi0