-
Notifications
You must be signed in to change notification settings - Fork 29.8k
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
Backport ESM loader changes to 18.x #48042
Comments
Did you check the backporting guide? node/doc/contributing/backporting-to-release-lines.md Lines 11 to 25 in a0440c9
TL;DR all commits that have landed on a current release branch will be backported "automatically" to the active LTS branches after a maturation period. If the commit doesn't land cleanly, the person preparing the release will add a comment to the PR asking for a manual backport. v18.x is an active LTS release line at the time of writing, see the Release Schedule. |
@aduh95 the PR in question had dont-land-on-v18.x previously, which may have broken the automation because it was previously skipped. it's now set to requested backport. |
@aduh95 should this be reopened given the above comment from @lizthegrey ? |
This PR was not in fact backported via the usual automated means into Node 18.17.0 LTS last week. We request re-opening this issue since the automation has not backported it automatically. @aduh95 @MoLow @arcanis @bencmbrook |
To be clear, there are no automations in place, the process is very much manual: the volunteer for the LTS release will cherry-pick all the commits that have landed in v20.x – except the ones who do not land cleanly, and/or have a |
Oh! That clarifies a lot about how this PR got missed, and now that it's clear that contributing a backport PR is what's required, I can certainly have a go at it. |
What is the problem this feature will solve?
Pulling this request (#43772 (comment)) into its own Issue.
This would allow chaining loaders in Node 18.x (and unlock many Yarn PnP use-cases without having to wait for 20.x LTS)
What is the feature you are proposing to solve the problem?
Backport the changes related to "ESM: Leverage loaders when resolving subsequent loaders".
What alternatives have you considered?
No response
The text was updated successfully, but these errors were encountered: