-
-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
chore: remove import-meta-resolve #13629
base: main
Are you sure you want to change the base?
Conversation
🦋 Changeset detectedLatest commit: 381457e 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 |
import { dirname, join } from 'node:path'; | ||
import { existsSync } from 'node:fs'; | ||
import path from 'node:path'; | ||
import fs from 'node:fs'; | ||
import process from 'node:process'; | ||
|
||
/** @type {Record<string, (name: string, version: string) => string>} */ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This logic exists in package-manager-detector
(used by svelte CLI, changesets, and publint). It might be good to use here too as it supports Deno, which I notice we're not supporting here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe we could just follow this PR up with one that adds Deno support? Or is there a reason to strongly prefer adding the dependency?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah, we probably could. I think the main reason to possibly prefer the dependency is that getting some of the commands right for Deno has been maddeningly difficult. even now there's an issue open that the install command is not working correctly: antfu-collective/package-manager-detector#51
I learned from @pi0 in #13513 that
import.meta.resolve
no longer takes a second argument, meaning it can't be used for resolving a peer dependency relative to the current working directory. As such, we won't be able to migrate to it once it's supported everywhere we care about.So unless we intend to keep
import-meta-resolve
around forever, we should just get rid of it now. I don't think we need to use a library for this (especially since we know which packages we're using this with, and so don't need to deal with any weird edge cases) — we can just implement the logic ourselves. This PR adds aresolve_peer
function which is duplicated betweenpackages/kit
andpackages/adapter-auto
, since a little duplication is better than faffing around with a more convoluted package structure.Closes #13528 (which has the 3.0 milestone, but this isn't a breaking change so we can do it immediately)
Please don't delete this checklist! Before submitting the PR, please make sure you do the following:
Tests
pnpm test
and lint the project withpnpm lint
andpnpm check
Changesets
pnpm changeset
and following the prompts. Changesets that add features should beminor
and those that fix bugs should bepatch
. Please prefix changeset messages withfeat:
,fix:
, orchore:
.Edits