Add option to omit the index.css file from a ESM / CommonJS library build

[drewdecarme]

🙋 feature request

When using the library feature with some sort of styling (Sass, CSS, etc...), those assets are compiled and then added to the index.css output. As of this moment, that index.css file is auto included in the library bundle at the top of the file.

This is handy in some cases where the consumer doesn't have to worry about including the CSS for the component, but this does technically create a side effect for the library and at the moment does violate some rules that NextJS has in place; namely the global inclusion.

Here's the error in NextJS.

Global CSS cannot be imported from files other than your Custom <App>. Due to the Global nature of stylesheets, and to avoid conflicts, Please move all first-party global CSS imports to pages/_app.js. Or convert the import to Component-Level CSS (CSS Modules).
Read more: https://nextjs.org/docs/messages/css-global

In addition, if using a "type": "module" in the package.json to mark your library as a module, you'd probably want to mark it as "sideEffects": "false" since some bundlers, namely webpack uses that field for better tree shaking.

🤔 Expected Behavior

The bundler functionality for libraries should output the CSS used in the components, but not auto included at the top of the file. The consumer of the library should have to import/require the file themselves in their app.

😯 Current Behavior

The compiled styles are auto included at the top of the library bundle.

Here's what the ESM output looks like at the moment.

import "./index.css";
import $lTwnu$clsx from "clsx";
import $lTwnu$react from "react";

function $parcel$exportWildcard(dest, source) {
  Object.keys(source).forEach(function(key) {
    if (key === 'default' || key === '__esModule' || dest.hasOwnProperty(key)) {
      return;
    }

    Object.defineProperty(dest, key, {
      enumerable: true,
      get: function get() {
        return source[key];
      }
    });
  });

  return dest;
}
// the rest of the build

💁 Possible Solution

Add a CLI or a configuration control in the .parcelrc

🔦 Context

I can use create-react-app fine, as this control isn't a requirement for a fully client-side app, but when trying to use NextJS, the framework blows up preventing my ability from using parcel to bundle my NextJS component libraries.

💻 Examples

I have a GitHub repo at the moment that runs into this issue. Clone it then run yarn && yarn next:dev. Navigate to /buttons and you'll see the error. The repo uses Yarn workspaces to manage multiple packages.

[devongovett]

I'd consider this a bug in Next. I believe they are planning on allowing global CSS from node_modules soon as well vercel/next.js#27953

[devongovett]

To expand on this slightly, if you don't want the output bundle to import css, then don't import any CSS from your JavaScript source files. Instead, you can make your CSS file an entry.

So rather than this:

parcel build src/index.js

// index.js
import './index.css';

// ...

Do this:

parcel build src/index.js src/index.css

// index.js
// Don't import any css

[drewdecarme]

Thanks, I'm eager for that solution in NextJS. When I first saw the error, it seemed platform-specific to me, but I figured that I'd raise a feature request to see if it was feasible on the Parcel side.

@devongovett I originally did try to separate out the entry files using the targets in Parcel2 but adding a single target ignored the main, module, and types keys in the package JSON. I tried adding all of those keys to the targets, but ultimately, my type declarations weren't being generated. In addition, I was using CSS Modules with Sass and I need to import that CSS file in order for that class name transformation to take place.

With that said, I'm coming from a Webpack world and definitely appreciate the way that Parcel is trying to move the needle on the consistent norm of library configuration hell. I'm really enjoying the configuration and the examples are nice and clear. The default inclusion of swc gives me the warm and fuzzies

[nicksrandall]

@devongovett I agree with @drewdecarme that this is an important feature. If I'm building a component library, I would like the bundled output to not require any more bundling so that library authors can reference files directly from things like unpkg.com . I think the CSS file should still be generated but there should be an option to omit the non standard require('index.css') or import 'index.css' from the bundle so that the file could be directly used by a browser.

If library authors choose to enable this feature, they will also need to explain to their users on how to manually include the css but in my case that is acceptable.

Also, IIRC, esbuild never adds the additional require statement and always requires the CSS to be manually added so there is a precedent for that among bundlers.

[yw662]

This can also be a bug when building multi-page sites. If all the pages automatically import index.css, some may not work as intended, especially when some of the rules are not from a css module.
The css files may be better bundled "locally" or "individually" for each particular build target, or inlined into the html file.

[TechQuery]

I fixed this issue with an extra script for now:
https://github.com/idea2app/Idea-React/pull/20/files#diff-2e2657e57be39ece5cd084a8ab00a31910948a08b0497fdb3134809852fff40d

[TechQuery]

@parcel-bundler anyone look about this issue?

[reda-alaoui]

I am still interested in this.

[TechQuery]

We may support Import Assertion standard proposal for CSS modules to resolve this:

1. https://www.proposals.es/proposals/Import%20Assertions
2. https://web.dev/articles/css-module-scripts
3. https://fullystacked.net/import-attributes/
4. Support import attributes #7648

[reda-alaoui]

I am still interested in this.

[Ralle]

Also interested in this.