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

CSS processors aren't considered installed if root is placed outside of vite.config's folder #2612

Closed
3 tasks done
bjarkihall opened this issue Mar 20, 2021 · 11 comments
Closed
3 tasks done

Comments

@bjarkihall
Copy link

bjarkihall commented Mar 20, 2021

⚠️ IMPORTANT ⚠️ Please do not ignore this template. If you do, your issue will be closed immediately.

Describe the bug

<root> describes the path of index.html, essentially where the static file server is running but it's also used as the root when searching for npm packages, which I'd rather think would be where vite.config is actually placed (or at least it should be used as a fallback).

I looked for potential duplicates and we started off a discussion on discord but it makes sense to raise this as a bug report to either clarify if you'd like this functionality to work at all (or identify potential blockers for this) or mention the limitation and reason in the docs.

Reproduction

Lets say you have the following folder structure:

A
  /package.json (npm i -D vite sass)
  /vite.config.js (export default {root: "../B/"})
B
  /index.html (uses /styles.scss)
  /styles.scss (causes error: Internal server error: Preprocessor dependency "sass" not found. Did you install it?)

So the idea here is that you run npm/yarn in folder A but the root of index.html (and its relative resources) is inside folder B (or C,D,E..., depending on the vite.config <root>).
Folder A defines the dev-server and the other folder defines what's being served.

Everything seems to run smoothly but the compileCSS function seems to send config.root to loadPreprocessor which fails, since the css-plugin (e.g. sass) isn't installed in the <root> so an error is thrown: Preprocessor dependency "${lang}" not found. Did you install it?.

Wouldn't it make sense if the process would also fallback to the node_modules where vite process is running, if the <root> is different?

A possible fix would be for loadPreprocessors to accept roots: string[] instead of root: string which would be used by require.resolve (or just add the fallback locally within the loader so you can keep the arg as a single root).

System Info

  • vite version: master (2.1.2)
  • Operating System: Win10
  • Node version: 12/14
  • Package manager (npm/yarn/pnpm) and version: npm 6/7

Logs

19:16:33 [vite] Internal server error: Preprocessor dependency "sass" not found. Did you install it?
  Plugin: vite:css
  File: C:/repro/B/styles.scss?direct
      at loadPreprocessor (C:\repro\A\node_modules\vite\dist\node\chunks\dep-6f1d3d8c.js:19061:15)
      at scss (C:\repro\A\node_modules\vite\dist\node\chunks\dep-6f1d3d8c.js:19067:20)
      at compileCSS (C:\repro\A\node_modules\vite\dist\node\chunks\dep-6f1d3d8c.js:18838:40)
      at async TransformContext.transform (C:\repro\A\node_modules\vite\dist\node\chunks\dep-6f1d3d8c.js:18523:50)
      at async Object.transform (C:\repro\A\node_modules\vite\dist\node\chunks\dep-6f1d3d8c.js:43642:30)
      at async transformRequest (C:\repro\A\node_modules\vite\dist\node\chunks\dep-6f1d3d8c.js:59301:29)
      at async C:\repro\A\node_modules\vite\dist\node\chunks\dep-6f1d3d8c.js:59409:32
@bjarkihall bjarkihall changed the title CSS processors aren't considered installed if <root> is placed outside of vite.config's folder CSS processors aren't considered installed if root is placed outside of vite.config's folder Mar 20, 2021
@bjarkihall
Copy link
Author

For reference: https://vitejs.dev/guide/#index-html-and-project-root

The expected behavior is for root to be an entry point for the server, so I believe the server is using the wrong path to resolve plugins when compiling (which isn't necessarily the same path you use for import resolution). I'm not sure if it's only affecting css plugins/preprocessors - it was just the first thing that broke when I tried this setup out.

Please ask if something isn't clear, I'd like to help.

@HomyeeKing
Copy link
Contributor

it works fine here
can you offer a mini-repo to reproduce this?

@github-actions
Copy link

Hello @bjarkihall. Please provide a online reproduction by codesandbox or a minimal GitHub repository. Issues labeled by need reproduction will be closed if no activities in 3 days.

@bjarkihall
Copy link
Author

bjarkihall commented Mar 24, 2021

This can't be reproduced on codesandbox I believe, here's a repo (just like I described in the issue description):
https://github.com/bjarkihall/vite-css-repro

@bjarkihall
Copy link
Author

@HomyeeKing where was your package.json and where were you running vite from?
cd ./A is the important step, as it makes sure the node root is not the same or a descendant of the B folder, which you're serving.
The error is still there after a fresh install in the minimal repro repository.

Please note, that if the B folder has package.json or an ascendant does OR if sass is globally installed (which might be your case?) this won't reproduce as node will resolve the module from there (which is a false negative).

@HomyeeKing
Copy link
Contributor

HomyeeKing commented Mar 26, 2021

yes, seems better to consider where vite.config.js file located
but I still want to ask what this scenario? just looks like you split the config file and develop file into 2 parts

you can do the same thing with B inside of A

@bjarkihall
Copy link
Author

bjarkihall commented Mar 26, 2021

@HomyeeKing yeah, the repro is just with the minimum amount of files to showcase the issue.
It's really about the server being placed separately from what it is serving.
Server is in folder A and Client is in folder B.

In my original setup where the error occurred, there was a much larger monorepo where package.json was inside one "bundling" folder which has a task runner that builds multiple builds from multiple folders/projects - then vite is used to serve these different builds separately, which theoretically could be output into a completely different folder on the computer too.

Previously, each output needed either a live-server or some configurations via IIS but vite works as a handy replacement for these typical static dev servers - it just needs a path to the index.html. :)

Also, only 1 package.json + node_modules is needed to resolve the server's dependencies now too, regardless of "what" it is serving and from "where" - plus, vite can also handle everything being unbundled + css/js plugins, like sass/ts, etc.

Thanks for looking into this and making the PR, I wasn't sure if this was the right way to do it and wanted feedback before submitting a fix. Do you know if other plugins (like js/imgs/wasm, etc.) that are being compiled are affected too? I did a short check and it doesn't seem like they are handled in the same way as css plugins, so I guess they're ok?

@HomyeeKing
Copy link
Contributor

HomyeeKing commented Mar 27, 2021

yes, they are handled differently, you can look through the vite docs to see how the other assets are processed

ferdinando-ferreira added a commit to ferdinando-ferreira/vite that referenced this issue May 9, 2021
@bjarkihall
Copy link
Author

@HomyeeKing would it make more sense to simply use process.cwd() like @ferdinando-ferreira did in this fork?
It isn't necessarily the vite.config file's root, but normally the package.json file's path instead - where you'd expect the node_modules folder to be.
I actually just used paths: [root, __dirname], since that would almost guarantee we look for sass in the same place where vite is installed and it solved my issue, I'd also figure it would be less prone to conflicts.

@ferdinando-ferreira
Copy link
Contributor

@bjarkihall : I didn't expand on that fork because using a global (and node dependent) variable in that place is not the best way to solve the issue.

If that PR doesn't advance I may propose an alternative without this flaw

@patak-dev
Copy link
Member

Closed by #3988, please report back if you find issues @bjarkihall. Thanks @ferdinando-ferreira for the heads up 👍🏼

@github-actions github-actions bot locked and limited conversation to collaborators Jul 16, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants