Skip to content
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

Support resolve.alias per environment in Environments API #17582

Open
4 tasks done
lazarv opened this issue Jun 27, 2024 · 2 comments
Open
4 tasks done

Support resolve.alias per environment in Environments API #17582

lazarv opened this issue Jun 27, 2024 · 2 comments

Comments

@lazarv
Copy link

lazarv commented Jun 27, 2024

Description

As a developer using Vite I want to use the Environment API and different resolve.alias per environment so that the same module name resolves to different files (like different filename suffix) or an environment adds more alias as it needs to resolve some modules differently than the others. Currently this is only possible by creating new environment instances and patching the config received in createEnvironment. Also https://github.com/vitejs/vite/blob/v6/environment-api/packages/vite/src/node/idResolver.ts#L43 and https://github.com/vitejs/vite/blob/v6/environment-api/packages/vite/src/node/idResolver.ts#L77 TODO comments are suggesting this was already a consideration.

Suggested solution

Create a facade vite:alias plugin, which proxies alias resolution requests to @rollup/plugin-alias instances based on the current environment or using the original entries when resolve.alias was not defined on the environment.

Alternative

No response

Additional context

No response

Validations

@sapphi-red
Copy link
Member

A common way to resolve a import specifier to a different module depending on the environment is to use conditional exports/imports. For example, RSC uses it like this.
Would that cover your needs?

cc @patak-dev

https://nodejs.org/docs/v20.15.0/api/packages.html#community-conditions-definitions
https://runtime-keys.proposal.wintercg.org/#example-usage

@lazarv
Copy link
Author

lazarv commented Jun 29, 2024

In fact I use resolve.alias for React, aliasing react, react-dom and react-server-dom-webpack exports to absolute paths in case of client/ssr environments, but not for rsc. I know my use case is niche and unconventional, still it just works this way. But during trying to clean up and strip down my Vite config in my React meta-framework I noticed that while alias is part of EnvironmentResolveOptions at https://github.com/vitejs/vite/blob/v6/environment-api/packages/vite/src/node/config.ts#L221, the environment is not using this, just from the server config and also noticed the TODO comments. See playground test in PR at https://github.com/vitejs/vite/blob/f217c539e162bd6106bc8606b601f71615fcf3b1/playground/environment-alias/vite.config.js. Sometimes changing the exports of a package is not possible as the developer's requirements is not the same as the package maintainer's.

Some context for this: a developer using my framework doesn't need to install anything to start a React app, using npx it's possible to just run npx @lazarv/react-server ./App.jsx and it just works, without any other packages installed or the developer just need add my framework as dependency and nothing else. React is resolved from inside the framework.

You can even do this: curl https://gist.githubusercontent.com/lazarv/23ea9a77f7061f3086a7516d3e7edd2d/raw/4b621ea2a17fefcb9b690edd7edf57393a5da03f/App.jsx | npx @lazarv/react-server --open

Where the gist contains an RSC:

export default function App() {
  return (
    <html lang="en">
      <head>
        <title>My App</title>
      </head>
      <body>
        <h1>Hello, world!</h1>
      </body>
    </html>
  );
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants