fix: include marko extensions when scanning dependencies

[DylanPiercey]

Description

Adds .marko as one of the file extensions to consider when performing the dependency optimization scan.

Additional context

Currently due to the way @marko/vite is setup it relied exclusively on optimizeDeps.include and not the dependency scanning so adding this change does break existing Marko apps.

However @marko/vite is being updated to use optimizeDeps.entries instead since the include method we were using needlessly bundles more than necessary.

The actual processing of Marko files is done by an esbuild hook added by @marko/vite so no further change is needed here other than allowing .marko files to pass through the isScannable checks.

---

What is the purpose of this pull request?

• Bug fix
• New Feature
• Documentation update
• Other

Before submitting the PR, please make sure you do the following

• Read the Contributing Guidelines.
• Read the Pull Request Guidelines and follow the PR Title Convention.
• Check that there isn't already a PR that solves the problem the same way to avoid creating a duplicate.
• Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #123).
• Ideally, include relevant tests that fail without this PR but pass with it.

[bluwy]

This LGTM, but I have a couple questions:

1. Do you want to backport this to Vite 4? Would it break for Marko users if they don't have the latest @marko/vite plugin installed?
2. I checked the esbuild plugin added by @marko/vite. Just to confirm, is it compiling Marko files to html? Is it also expensive to do so? Something I notice in the past if compiling during scanning is that it makes startup really slow, so I hope it doesn't happen here too.

[DylanPiercey]

@bluwy thanks for taking a look!
It's not critical that this change is backported, we're happy to switch to Vite 5.

Regarding the startup speed, I think it could definitely be improved further. Currently the esbuild plug-in uses our full Marko compiler and ultimately responds with our hydrate output (which just includes island code/scripts for the browser). We do have our much faster bare parser that we could use just to extract the deps which I might swap to in a future @marko/vite version.

Having said that, currently @marko/vite marks all .marko files which can be referenced from the projects package.json as optimizeDeps.include. This is (in some of our apps) pulling in a ton of unnecessary components and making the start up super long.

Manually making this change in Vite along side a to be released version of @marko/vite dramatically speeds things up for us and solves some other issues we've discovered.

[bluwy]

Sounds good 👍 Yeah it would be a step up in perf with this approach anyways. I'm thinking we could fix this in a different way. Maybe it makes sense to support optimizeDeps.extensions during scanning to signal extensions that can both be scanned and prebundled. Right now it only means the latter. In cases I've seen so far, supporting both should be feasible.

The PR currently uses htmlTypesRE which isn't quite accurate as Marko isn't transpiling to html. With optimizeDeps.extensions I think it should also work for Marko as it sets it there too: https://github.com/marko-js/vite/blob/5b89c7e3e0ee5bfd532b51778c47537bf1c3c969/src/index.ts#L297C37-L298.

In that case, we'd need to update isScannable to also take in account of optimizeDeps.extensions. What do you think?

[DylanPiercey]

@bluwy that option does seem better to me. I think ideally Vite starts to remove this kind of framework specific code / checks and this helps in that regard.

I put up #14543 as an alternative PR to this although I'm happy for either to land.

[bluwy]

I'll close this for now as #14543 is merged. If you'd like to backport this to Vite 4, I feel like it's safer to do the same as #14543 but only hardcode .marko for now. You can submit a PR to the v4 branch.

Note that initially it's planned that Vite 5 stable comes around mid-October, and it's already mid-October 😬 So might extend till late October now, and will try to not pass that time.