withastro / astro

The web framework for content-driven websites. ⭐️ Star to support our work!
https://astro.build
Other
45.94k stars 2.42k forks source link

🐛Root field ignored by integrations, widespread, monorepos #10570

Open luchillo17 opened 6 months ago

luchillo17 commented 6 months ago

Astro Info

Astro                    v4.5.10
Node                     v20.11.0
System                   Linux (x64)
Package Manager          pnpm
Output                   static
Adapter                  none
Integrations             @astrojs/tailwind
                         astro-icon
                         @astrojs/vue

If this issue only occurs in one browser, which browser is a problem?

No response

Describe the Bug

  1. The Astro add command relies heavily on package.json location, in integrated monorepos the location of the package.json is usually located 2 levels up in the folder structure, so instead of doing pnpm exec astro add astro-icon, I'm forced to install manually.
  2. The integrations resolve paths based on the process pwd instead of relative to the Astro config file, in monorepos it is common to run commands from the root of the monorepo instead of the root of the Astro app, thus the default paths of many integrations do not resolve to the expected path/folder inside the App.
  3. The root prop in the config seems to be ignored in many (if not all) integrations, thus we're forced to provide absolute paths when customizing the integrations folders:
    
    // astro.config.mjs
    import tailwind from '@astrojs/tailwind';
    import vue from '@astrojs/vue';
    import icon from 'astro-icon';
    import { defineConfig } from 'astro/config';
    import { join } from 'node:path';

// https://astro.build/config export default defineConfig({ root: import.meta.dirname, outDir: '../../dist/apps/portfolio', integrations: [ tailwind({ configFile: join(import.meta.dirname, './tailwind.config.mjs'), }), icon({ iconDir: join(import.meta.dirname, './src/assets/icons'), }), vue(), ], i18n: { defaultLocale: 'en', locales: ['en', 'es'], }, });



### What's the expected result?

- [ ] Doing `astro add` in a nested folder works regardless of where the `package.json` is located (usually 2 levels up in the file tree).
- [ ] Make the integrations work relative to the config file `astro.config.mjs`.
- [ ] If we setup the `root` field in the config, the integrations should take it as their root as well.

### Link to Minimal Reproducible Example

https://github.com/luchillo17/graph-meister-public/tree/hotfix/EACCES-dev-error

### Reproduction steps

1. Clone the repo and `cd apps/portfolio`.
2. Try to add one of the integrations like `pnpm astro add astro-icon`.
3. See error ` ERR_PNPM_NO_IMPORTER_MANIFEST_FOUND`.
4. Try with `pnpx astro add astro-icon` to use the remote astro version instead (will download the latest instead of using the local version).
5. Check how it creates a `package.json` instead of modifying the one 2 levels up.
6. Remove `package.json`, `pnpm-lock.yaml` and `node_modules` from `portfolio`.
7. Install integration from root folder with `pnpm add astro-icon`.
8. Run the portfolio with `pnpm exec nx run portfolio:dev`.
9. Use the `src/icons/bars.svg` anywhere as `<Icon name='bars' />`.
10. Get `[ERROR] Unable to load the "local" icon set!` (the file exist but the process path is at the root of the project, not at the portfolio app folder).
11. Try and fail to setup the integration folder with relative path in the config as `icon({ iconDir: './src/icons' })`.
12. Be forced to use absolute path with `join` and `__dirname` as `root` property doesn't work. (if using ESM it would be `import.meta.dirname`).

### Participation

- [X] I am willing to submit a pull request for this issue.
luchillo17 commented 6 months ago

Please note this same issue about paths being broken in monorepos happens with other integrations, so far has happened with @astrojs/tailwind, astro-icon, and with astro-i18n (though astro-i18n uses the middleware instead so the issue with this one could be that I need to set its NPM scripts to run from the portfolio folder).

whjvenyl commented 6 months ago

Just stumbled upon the same issues trying to set up a documentation site for my library. (wanted to use a subfolder for the docs, not even a full monorepo) 😑

jkhaui commented 6 months ago

I've also been experiencing a lot of strange issues when trying to set a custom root path in the astro config using a monorepo setup (I also programmatically run the dev server using the dev function).

I think I've overcome most of the issues also by using absolute instead of relative paths, but there's still a couple leaving me completely baffled:

  1. If I include a tailwind config file, it will get picked up by the astro config. However, the dev server fails to start and displays an error Error: [postcss] Cannot find module './path-to-some-local-file.js'.

But if I don't include a tailwind config file, then I can start the dev server, but... well obviously tailwind styles don't get applied as the content field isn't correctly applied

  1. Astro islands fail to hydrate. The browser console shows the following errors:
    • Failed to load module script: Expected a JavaScript module script but the server responded with a MIME type of "text/html". Strict MIME type checking is enforced for module scripts per HTML spec.
    • [astro-island] Error hydrating /@id/C:/Users/.../src/outlet.js TypeError: Failed to fetch dynamically imported module: http://localhost:3000/@id/C:/Users/.../src/outlet.js

P.s. Sorry if it looks like I somewhat hijacked this thread, but I believe these issues might indicate a more general problem with how Astro handles custom root paths

edit: managed to solve issue 1. which turned out to be some bizarre behaviour with an index file re-exporting a module using barrel exports. PostCSS may have been the culprit here. At this stage, I'm honestly not sure what's an Astro issue, or a Vite issue, or a monorepo setup thing - I just remember behaviour being a lot more predictable before setting the root field (which is now necessary in my project)

To end on a more positive note: big thanks to the Astro team for the effort in exposing comprehensive APIs and a great dev experience 🙏