Bjorn Lu

Pushed a commit with some styling changes after discussing with other maintainers, here's how it looks now: The hardcoding isn't the most ideal, but I think it simplifies the code...

Yeah I did try that but to do so and others, it slows creeps in as a lot of code compared to hardcoding. So I leaned directly to the simplest...

Yeah that was also the part where I threw my hand and went for the simpler path instead 😄 It's hard to sort that one with a specific hardcoding too.

In the last meeting, we decided to prefer an explicit approach instead because we don't want users to accidentally build HTML files in `test-results` or `__tests__`, or an any potential...

I think that's also an interesting way to look at it. I would prefer chaining `.public()`/`.private()` first, and then chain `.client()`/`.server()`, as the bonus with this is that we can...

> In a [fluent API](https://en.wikipedia.org/wiki/Fluent_interface) (another name for chaining) the expectation is that they can be chained in any order as they are operating on a common `this` value. If...

Using `import { FOO }`, `import * as AstroEnv`, or `import AstroEnv` (if we support this) will all work with Rollup's treeshaking, so I don't think we have to change...

/ecosystem-ci run

What is the usecase for accepting a `resolver` option? Vite has its own internal resolver too and it should use that. Similar to how `postcss-import` and CSS preprocessors like SCSS,...

In that case, it seems like a bug (or technically a feature request) to me to make import globs work with lightningcss. There's also a corresponding postcss feature request: https://github.com/vitejs/vite/issues/12336....