Could you link or explain the issue you are trying to solve? Please also add a test to one of the playgrounds to avoid future regressions

Hi @patak-dev,
I already linked the issue under the pr description. The issue is #6582. I will add tests to a playground soon 👍

#6582 (comment)

I think it isn't bad to support this, at least to avoid the inconsistency between build and dev. @bluwy what do you think?

external could be something different than an array though. See

export type ExternalOption =
	| (string | RegExp)[]
	| string
	| RegExp
	| ((source: string, importer: string | undefined, isResolved: boolean) => boolean | null | void);

There should be code that we could grab from rollup to do this check.

An id could also be marked external by a plugin, like

function externalizeDependencyPlugin() {
  return {
    name: 'externalize-dependency',
    resolveId(source) {
      if (source === 'my-dependency') {
        return { id: 'my-dependency-develop', external: true };
      }
      return null;
    }
  };
}

But we could implement support for this separately (if we end up doing it).

Yeah I think this make sense too. And you're right with the complex types, Rollup has an API for that:

(await this.resolve(id))?.external

this.isExternal is deprecated.

Thanks for the PR @hasangenc0, but I don't think this is the right way to handle external in import-analysis. rollupOptions.external also accepts an array, regex, and function too, so this won't be handled correctly for those cases. Furthermore we should probably bail early for externalized imports instead of letting it flow through Vite plugins to be compatible with Rollup.

I've made a comment at #6582 (comment) with an early implementation of it. It's still missing tests and an API. Feel free to take over that branch if you'd like to implement it!