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

Deprecate deps.inline in favour of deps.optimizer #3521

Open
4 tasks done
sheremet-va opened this issue Jun 5, 2023 · 5 comments
Open
4 tasks done

Deprecate deps.inline in favour of deps.optimizer #3521

sheremet-va opened this issue Jun 5, 2023 · 5 comments

Comments

@sheremet-va
Copy link
Member

sheremet-va commented Jun 5, 2023

Clear and concise description of the problem

Currently, it is not very obvious to most users how deps.inline works and why it needs to be used for certain packages. It also doesn't work with monorepo packages when string version is used (internally it just checks node_modules/{name}).

This option also makes tests run slower because Vitest needs to process these files through Vite pipeline one by one which is not very optimal. This is also not what Vite itself is doing when it's running in the browser.

On the other hand, deps.optimizer does the same thing that Vite does with the package in the browser - it pre-bundles it into a single entry point. This makes it faster to import, fixes CJS compatibility issues, and allows the use of plugins and aliases on a just single compiled file.

Vitest provides this option for quite some time, but we hit the wall with how the optimizer works in the browser. When it hits the new module, Vite just reloads the page and starts optimizing again - we can't do this so easily in our case. We also don't want to bundle actual Node.js packages that are used in setup files, for example. To solve this issue, Vite team introduced noDiscovery option in Vite 4.3. Theoretically, this should solve our issues and be an alternative to deps.inline.

Suggested solution

To make the transition clear, we should deprecate deps.inline, deps.exclude, and deps.registerNodeLoader with a message: Use "deps.optimizer" instead.. Instead of removing these options completely, we should provide them in a new option called server for those who prefer using Vite Node to run their source code instead of native Node (the name of the option is debatable - we can't name it viteNode, because the project will have a different name by the time it is implemented in Vite core).

Validations

@silverwind
Copy link
Contributor

silverwind commented Jun 27, 2023

One use case where deps.inline is neccessary is when a module ships CSS imports, e.g. import './style.css'. Vite knows how to load CSS, but vitest doesn't and throws an error.

Will deps.optimizer help with that, or even better, will there be an automatic solution to CSS imports, e.g. like dynamically creating a <style> element in the virtual DOM (assuming jsdom or happy-dom)?

@sheremet-va
Copy link
Member Author

One use case where deps.inline is neccessary is when a module ships CSS imports, e.g. import './style.css'. Vite knows how to load CSS, but vitest doesn't and throws an error.

Will deps.optimizer help with that, or even better, will there be an automatic solution to CSS imports, e.g. like dynamically creating a <style> element in the virtual DOM (assuming jsdom or happy-dom)?

deps.optimizer works more like Vite works in the browser. deps.inline works like if you disable optimzieDeps.

@BenjaBobs
Copy link

Will deps.inline be completely removed/ignored at some point?
I'm dealing with a package that doesn't have a default/single entry point, but instead exposes many entry points without a default.
With deps.optimizer I run into The package may have incorrect main/module/exports specified in its package.json: Missing "." specifier in "<package>" package, however with deps.inline it just works.

@sheremet-va
Copy link
Member Author

The idea is to make it easier to work with. We are currently gathering feedback and it looks like this option will stay in one form or another. Ideally, we would like these packages to just work out of the box.

@GuskiS
Copy link

GuskiS commented Nov 21, 2023

Might be hijacking thread, but is there a plan for vite-node to allow reading values from config file?
I'm trying to run vite-node --config vite.config.ts ./server.ts but this doesn't seem to work, with this config:

    test: {
      deps: {
        external: [/some-package/],
      },
    }

If I do vite-node --config vite.config.ts --options.deps.external='/some-package/' ./server.ts it works.

(got here because I also have similar issue with package that exposes many entry points)

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

4 participants