fix(nuxt): pass (and handle) relative paths in builder:watch

[danielroe]

🔗 Linked issue

❓ Type of change

• 📖 Documentation (updates to the documentation or readme)
• 🐞 Bug fix (a non-breaking change that fixes an issue)
• 👌 Enhancement (improving an existing functionality like performance)
• ✨ New feature (a non-breaking change that adds functionality)
• 🧹 Chore (updates to the build process or auxiliary tools and libraries)
• ⚠️ Breaking change (fix or feature that would cause existing functionality to change)

📚 Description

For chokidar-granular and parcel watcher options, watch events emit the absolute path. For chokidar, the path was relative to srcDir. (This was an unintentionally breaking change when #20836 was merged and later made default.)

This PR:

• Makes chokidar-granular and parcel watchers also emit relative paths. The reason I've chosen this rather than reverting to previous behaviour is that 3.7 is a minor release so we can make a more significant change to this behaviour. In addition, I think it makes more sense to have absolute path when handling things like watching layers in a monorepo, which may not be 'within' the source directory of the project. However, I would welcome thoughts on this. (We could instead emit all paths as relative in parcel/chokidar-granular for backwards compatibility.)
• Adds support for treating layers as first class citizens with regard to restarting - changes to pages/layouts/middleware/composable/etc. will now be treated in the same way as changing the source project.
• Other improvements include not restarting when directories that start with the same pattern are changed/updated (e.g. ~/composablestest

Related: #22307.

TODO:

• consider emitting relative paths for backwards compatibility and moving to absolute paths in a future major release. How significant do we feel this change is?

📝 Checklist

• I have linked an issue or discussion.
• I have updated the documentation accordingly.

[stackblitz]

Run & review this pull request in StackBlitz Codeflow.

[manniL]

The reason I've chosen this rather than reverting to previous behaviour is that 3.7 is a minor release so we can make a more significant change to this behaviour.

Makes sense, especially because the majority of users won't rely on these paths directly.

In addition, I think it makes more sense to have absolute path when handling things like watching layers in a monorepo, which may not be 'within' the source directory of the project. However, I would welcome thoughts on this. (We could instead emit all paths as relative in parcel/chokidar-granular for backwards compatibility.)

To me this sounds reasonable, especially given no issues/feedback (known to me) to the absolute vs. relative path changes. And better monorepo layer support is another big benefit here 👍🏻

[danielroe]

Here are some examples of where people are already expecting fully resolved paths (likely in response to this unintentional change):

• https://github.com/nuxt/devtools/blob/f1c5c9e0d158a17f60b25a750442aaea0c5ef607/packages/devtools/src/server-rpc/assets.ts#L12-L22
• https://github.com/nuxt-modules/apollo/blob/c93fbf0b0af2b0fcfe241d67669ad72c70d7251d/src/module.ts#L174

Here are some examples of where people are handling relative paths:

• https://github.com/loicpennequin/game-portal/blob/c330b6599d37f2a6dc091bde0e9d3cefd5726e0f/packages/web/src/utils/nuxt-module.ts#L38-L41
• https://github.com/liornabat/nuxt-3-prime-ui/blob/a0cc4fa2484add5cce78de61446968d61c780747/src/modules/router.ts#L64-L69
• https://github.com/jerrywu001/jerrywu001/blob/558c99d97b0d40a87903e0b9818fccabe79f95df/modules/content/index.ts#L72-L76

There are other examples too.

Either way will require updating. It's likely easier for apollo/devtools to get an absolute path by resolve(nuxt.options.srcDir, path) which will work either with abs/relative paths being passed to them, than it would be to normalise back to relative path for modules using it.

[manniL]

Either way will require updating. It's likely easier for apollo/devtools to get an absolute path by resolve(nuxt.options.srcDir, path) which will work either with abs/relative paths being passed to them, than it would be to normalise back to relative path for modules using it.

Good point. Then indeed relative paths make more sense. We should keep a TODO or similar though for making them absolute in the next major.

[Hebilicious]

I think the change to absolute makes perfect sense.
I wonder what is the "blast radius", as modules which don't rely on startsWith are not affected.

https://github.com/Hebilicious/form-actions-nuxt/blob/581f8696c5768b7799dd4d10f45b77922e076c5e/packages/form-actions-nuxt/src/module.ts#L208
https://github.com/Hebilicious/server-block-nuxt/blob/a7f4ca2e2c464c23d731c00cfa9f1f007b42e1f8/packages/server-block-nuxt/src/module.ts#L67

[danielroe]

I've talked myself around. I'm thinking we should probably refactor this to emit relative paths again, even if we use absolute paths under-the-hood.

We can then change the behaviour in a major version.

Maintainers of modules who rely on absolute path can simply normalise paths with path = resolve(nuxt.options.srcDir, path) which will work with relative and absolute paths (if module is being used on a version of nuxt with this regression)....