Global CSS cannot be imported from within node_modules.

[samuelcastro]

Bug report

I can't import a css file from a node_modules 3rd party library as described here (https://nextjs.org/docs/basic-features/built-in-css-support#import-styles-from-node_modules).

This is the error I'm getting:

./node_modules/react-datepicker/dist/react-datepicker.css
Global CSS cannot be imported from within node_modules.
Read more: https://err.sh/next.js/css-npm
Location: node_modules/@edooking/ui/src/elements/DatePicker/DatePicker.tsx

It seems this was fixed before here #12079, but since I'm able to reproduce the issue again on Next.js 10.0.3 I'm re-opening the issue.

To Reproduce

Try to import a CSS from a 3rd party lib.

Expected behavior

To be able to import css

System information

• OS: macOS
• Chrome
• Version of Next.js: 10.0.3
• Version of Node.js: 14.4.0
• Deployment: vercel

Additional context

#12079

[timneutkens]

This is expected, this particular library is incorrectly publishing css imports to npm, looks like it even publishes JSX. Instead it should be exposed separately:

Location: node_modules/@edooking/ui/src/elements/DatePicker/DatePicker.tsx

Importing global css from node_modules is allowed like this in your code:

// Allowed
import 'react-datepicker/dist/react-datepicker.css'

// Not allowed
import DatePicker from '@edooking/ui/src/elements/DatePicker/DatePicker' // this then imports the css

Main reasons behind this are that we don't compile node_modules further, meaning those files can't be found during pre-rendering and would crash your application. It's also not compatible with esmodules so looking to the future it'll cause issues.

An example of correctly publishing a library like this is https://reach.tech/styling/

[samuelcastro]

@timneutkens @edooking/ui is an internal UI library that's is compiled in the main next.js application through next-transpile-modules so it's using the main next.js build process for compilation etc, I don't see why it wouldn't work.

[timneutkens]

It's probably a bug in next-transpile-modules which is an unofficial module that changes compilation internals.

[HitsiLent]

how can you control all 3rd part developer don't let them import css to their own library, that's don't make sense.

[newtoniumx3]

how can you control all 3rd part developer don't let them import css to their own library, that's don't make sense.

and this just happened to me -_- react-images-upload imports a css file and getting the error

[varya]

I am having the same issue — I cannot control how 3rd party library is making their imports.

[mayhs19]

Same is the case with patternfly and the patternfly team has mentioned it be a NextJS "drop in support" use-case (More details: patternfly/patternfly#4035).

I would humbly suggest the NextJS team to review this and explore the ability to give users an alternate solution, if possible.

[SoorajChandran]

This happens even with important libraries like CKEditor. Check this question here

[elodszopos]

This right here is basically a big doorstop for Tailwind 2.2

Issue here: tailwindlabs/tailwindcss#4681
Proposed fix on Tailwind-side, opened PR by contributor: tailwindlabs/tailwindcss#4725

[devongovett]

Please reconsider your position on this. Next.js is the only major web tool with this restriction. create-react-app, Gatsby, Parcel, vanilla webpack with css-loader, etc. all support importing CSS from anywhere. Restricting this for some philosophical reason only frustrates users of both Next.js and libraries that include CSS.

Let me explain why none of the workarounds explained in your docs are very good.

Reach out to the maintainer and ask for them to publish a compiled version of their dependency.

What does "compiled version of their dependency" even mean? CSS doesn't need compiling, it can be loaded directly in the browser. It's up to the library to properly scope their CSS class names somehow, but even if they don't, then it's up to the user building the app to deal with this however they need to. Next.js shouldn't be restricting how libraries are authored and consumed.

If this is referring to compiling the CSS into the JavaScript file (i.e. injecting style tags at runtime), then this is not a good solution either as this will result in poor runtime performance for all users, even when they don't use Next.js.

Also "reach out to the maintainer" results in tons of support requests to libraries for something that isn't their fault.

Compiled dependencies do not have references to CSS files, or any other files that require bundler-specific integrations.

Again, CSS doesn't require a "bundler specific integration". It's a web standard and should be supported by any tool. Next.js supports CSS generally, so why not in node_modules?

The dependency should also provide instructions about what CSS needs to be imported by you, in your application.

Requiring users to import the CSS for a library is not a good solution. For example, in a library with many components, you either have to provide a single CSS file with the CSS for the whole library (resulting in bloat), or individual files for each component. But users may easily forget to import the CSS for every component they use, in every file that uses this component (otherwise it might be missing depending on the entry point).

Also, each component may depend on more than one CSS file, and these may overlap. The solutions would either be to provide a single combined file per component that users would need to import, or list every single CSS file that they need to import manually in the docs. The first would result in duplicated CSS if multiple components actually share the same CSS source code. The second would cause a breaking change every time a component needs to add (or remove) a CSS dependency because users would need to manually import it.

Should the file be consumed as Global CSS or CSS Modules?

Global. Always. CSS modules should be pre-compiled before publishing to npm. As you say, dependencies shouldn't require any bundler-specific setup. CSS that's distributed with JS should be loadable in a browser directly.

If Global, in what order does the file need to be injected?

In the order it was imported, as every other tool works.

If Modules, what are the emitted class names? As-is, camel-case, snake case?

Already said CSS modules should be precompiled, but why would this even matter? With CSS modules, the JS doesn't care what the generated names are, it just uses the mapping returned from the module.

---

This is not some complicated problem - it's been solved by other tools for years. Next.js is literally just disabling css-loader from running on node_modules. If that restriction were lifted, everything would work as expected and match every other tool out there. Not doing so is simply making the DX worse for users of Next.js, and causing headaches for library maintainers who users complain to because they get errors when using the library with Next.js. Please fix it.