Run & review this pull request in StackBlitz Codeflow.

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 👍🏻

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.

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.

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

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)....