feat: resolve cssPath with resolvePath

[dcrall]

This change updates the way the cssPath option is resolved. Instead of resolveAlias it uses resolvePath This is the same mechanism used for the resolution of configPath. This allows module users to resolve a stylesheet provided by a dependency. In our case, we have a component library that includes a tailwind.css file that we would like to share between applications.

Testing change

• The module playground demonstrates the default behavior works as expected and includes runtime/tailwind.css.
• You can see the module resolve the CSS file from a dependency in the following sandbox where we load only Tailwind's base styles from the tawilwindcss package:
  • https://codesandbox.io/s/gifted-worker-g3lk8j?file=/playground/nuxt.config.ts

You can see annotated results in the screenshot below:

[atinux]

I am not sure to understand the issue here, do you have an example of the error created by resolveAlias?

By not using resolveAlias, the end user won't be able to use the ~ to link to its css file (ex: ~/assets/my-tailwind.css).

[dcrall]

@atinux Thank you for reviewing this change. Sorry for my slow response. I was out of the office last week.

resolvePath calls resolveAlias, so the common case of ~/assets/tailwind.css works as expected. Here is the call to resolveAlias.

To illustrate this, I've created three branches and pull requests under my fork that use the package @dcrall/tw-test, which simply exposes a tailwind config and stylesheet. In each branch, I've included screenshots showing the behavior.

The first branch shows the current module with the addition of a logging statement. No errors are thrown, but the module loads its own runtime/tailwind.css instead of the specified file from the package.

• Illustrate issue with resolveAlias dcrall/tailwindcss-module#3

The second branch shows the modified module successfully resolving the package's tailwind.css.

• Modified module working with @dcrall/tw-test dcrall/tailwindcss-module#4

The third branch shows the modified module successfully resolving the stylesheet from ~/assets/tailwind.css.

• Alias to assets working with modified module dcrall/tailwindcss-module#5

Please let me know if you have any more questions or concerns.

[pi0]

LGTM. resolvePath internally handles aliases too.

[pi0]

@dcrall Can we maybe improve this by providing extensions option? By default Nuxt resolves with all possible extensions such as .js and .vue while we probably only want to allow .css (and other style related ones)

[dcrall]

@pi0 I understood your extension comment to be a request to limit file resolution to .css (and related) files. Looking at resolvePath that does not seem to be the purpose of the extensions option. My testing indicates that will resolve ~/assets/tailwind as ~/assets/tailwind.css or ~/assets/tailwind as ~/assets/tailwind/index.css.

I have illustrated that case in the PR below. It works for resolving files in the project, but the resolution fails when resolving to a file in a package. To make the package resolution work, we would need to try module resolution against the extension array similar to the code above it.

• Tw test assets extensions dcrall/tailwindcss-module#6

Have I misunderstood? Are you thinking I should check the configured path against the extensions array?

[atinux]

From what I see here it works if you specify the extension in cssPath which anyway seems the best when dealing with non js-file and npm packages.

Thank you so much for all your reproductions and tests, I believe it is good to merge in that state 😊

[pi0]

It works for resolving files in the project, but the resolution fails when resolving to a file in a package.

This is almost correct. Using extensions is mostly useful for relative fs paths and not package resolution. Referencing to packages is probably even more beautiful without any extension and using exports subpaths.

[pi0]

LGTM.

[pi0]

I hope this isn't too verbose to be an info log (could be debug). Almost any internal of Nuxt is also adding kinda defaults.