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
fix: support windows absolute extends #3062
fix: support windows absolute extends #3062
Conversation
7444fcf
to
d8c7d60
Compare
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.
just one thought wondering if we could clean things up furhter. i havent dug in to better understand if that is a reasonable follow up or not, but i'm going to move this forward and we can do that as a separate PR if it does make sense.
thanks for sticking with this @sheerlox!
import { fileURLToPath } from "node:url"; | ||
|
||
import { castArray, isNil, isPlainObject, isString, pickBy } from "lodash-es"; | ||
import { readPackageUp } from "read-pkg-up"; | ||
import { cosmiconfig } from "cosmiconfig"; | ||
import resolveFrom from "resolve-from"; |
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.
is resolve-from still used elsewhere in the project? would it be possible to remove it as a 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.
Yes it is still being used in the loadPlugin
function, and we can't replace it with import-from-esm
it because doesn't support ESM named exports (it only returns the whole module if the default
export does not exist).
At least this part of the code is not subject to the Windows absolute path issue since the import
statement explicitly specifies the file://
protocol.
semantic-release/lib/plugins/utils.js
Lines 50 to 67 in d3aae07
export async function loadPlugin({ cwd }, name, pluginsPath) { | |
const basePath = pluginsPath[name] | |
? dirname(resolveFrom.silent(__dirname, pluginsPath[name]) || resolveFrom(cwd, pluginsPath[name])) | |
: __dirname; | |
if (isFunction(name)) { | |
return name; | |
} | |
const file = resolveFrom.silent(basePath, name) || resolveFrom(cwd, name); | |
const { default: cjsExport, ...esmNamedExports } = await import(`file://${file}`); | |
if (cjsExport) { | |
return cjsExport; | |
} | |
return esmNamedExports; | |
} |
🎉 This PR is included in version 22.0.8 🎉 The release is available on: Your semantic-release bot 📦🚀 |
Description
Restore support for Windows absolute path in the
extends
configuration option by usingimport-from-esm
to load the referenced module.Context
Following the changes in #3037, a user encountered an
ERR_UNSUPPORTED_ESM_URL_SCHEME
error because usingresolve-from
does not return an URL, andimport
then considersC:/
to be an URL scheme (likefile://
) and returns the encountered error.How has this been tested
Since there are no Windows-specific tests on this repository and the test pipeline doesn't run on Windows, we can rely on
import-from-esm
solid test suite to guarantee this works:index.json
& package main entry point JSON modules is now supported and covered by testsRelated issues