Experimental css - ignore order.

Feature request

MiniCssExtractPlugin: “ignoreOrder: true” available in the NextJS inbuilt css. Turning this option on should disable the need for css imports to only exist in _app.

Is your feature request related to a problem? Please describe.

Linaria is a css-in-js framework that provides css-in-js syntax similar to styled-components but extracts the css out to stylesheets at build time.

// before transpile
const Wrapper = styled.div`color: blue`;
const TriggerError = <Wrapper/>;

// after transpile (and through linarias build time plugins)
const Wrapper = styled.div({name: "Wrapper", class: "gjdasfhja"});
require("./home.casij5839.css"); // new file that its injected.
const TriggerError = React.createElement(Wrapper);

This require statement here triggers the error where that css obviously isn’t being imported into _app but into whatever page is using this file.

I understand why its impossible to guarantee order between sheets and therefore this is enforced but there should also be a escape hatch for people who don’t care about order between sheets.

This also goes onto a second point which is order of multiple sheets cannot be guaranteed HOWEVER order of styles WITHIN each sheet will always remain in the same order; This is good enough for 99% of use cases.

I.E SheetA.css SheetB.css SheetC.css could appear in conflicting orders depending on where they appear in nested import statements. However. All the rules within SheetA.css will always appear in the same order regardless of where its import statement is found.

Describe the solution you’d like

ignoreOrder: true option along with the experimental css; which allows importing css anywhere. This option forces people to think if this is something they want before opting in.

Describe alternatives you’ve considered

• Continue to use modified next-css plugin with ignoreOrder: true
• Hack a webpack extension like the code below which works but rely’s extensively on maintaining this every time next changes their webpack setup. Also is extremely risk to implement in production as there’s no guarantees it will work in the future.

    /* EDIT: Don't use this config; it's not fit for production use just merely as an example */
    webpack(config, options) {
        config.plugins.map((plg) => {
            if(plg.options && plg.options.ignoreOrder === false) {
                /* 100% sure we're MiniCssExtractPlugin AND is production */
                plg.options.ignoreOrder = true;
            }
            return plg;
        });
        const existing = config.module.rules.find((rule) => Boolean(rule.oneOf));
        if(existing) {
            existing.oneOf = existing.oneOf.filter((rule) => {
                const testStr = rule.test ? rule.test.toString() : "";
                const isLoaderCss= !testStr.includes("module") && testStr.includes(".css");
                if(isLoaderCss && rule.use.loader === "error-loader") {
                    /* is the error loader that prevents importing outside .app */
                    return false;
                }
                if(isLoaderCss) {
                    /* is a css loader with some includes regex that only matches _app remove it */
                    delete rule.issuer;
                }
                return true;
            })
        }
        return config
    },

Additional context

Helps with only importing critical css. https://github.com/zeit/next.js/tree/canary/examples/with-linaria Also use cases extend beyond this specific library. related code in webpack-config.ts that would have to be changed.

        new MiniCssExtractPlugin({
          filename: 'static/css/[contenthash].css',
          chunkFilename: 'static/css/[contenthash].chunk.css',
          // ignoreOrder: true  (As of NextJS 9.2+ this option is indeed here it seems)
        }),
        // both {test: ".css": loader: "error-loader"} plugins.
        // the  {test ".css", issuer: targets only custom _app loader 

[mikestopcontinues]

As a Linaria user, I second this request. I see this as the fundamental reason opinionated libraries are so brittle. No team has knowledge of the entire ecosystem, so any opinion is ultimately flawed. The best we can do as developers is adhere to conventions as firmly as possible and expect that our users will do the same. I’ve found the Next methodology has created ten problems for every one it’s solved. If Next didn’t wrap babel and webpack so tightly (and atypically), it wouldn’t need plugins and feature requests for issues that are easy to address with the underlying tech. Anyway, I would very much like to see a solution to this particular problem. 😄

[ShanonJackson]

@mikestopcontinues

Gave up on Linaria since writing this; As for the “10 problems for every 1 it solves”; My advice is this conform to the “Next” way closer and those problems will go away; Yes its a pain however iv’e seen the benefits.

Here’s my two cents on Linaria. Linaria is all the features of CSS + all the features of javascript. However the zero runtime cost is a lie because the styled() api produces a wrapped component. scss modules is all the features of CSS + all the features of SCSS. With explicit zero runtime cost guaranteed.

Both have loops/variables/iteration/etc etc etc except the only difference is the syntax changes depending on if you write the latter part in SCSS syntax or javascript syntax. With SCSS now you can also export your variables into the javascript world with a little magic.

My advice would be to leave Linaria, refactor to SCSS modules join me on “Easy street”. The Linaria team continuously ignores common sense improvements and doesn’t iterate on their library. Originally they had something good but now as time has passed its clear that they’re not willing to maintain it to a level that is required to seriously consider it as a viable option.

It was a pain to migrate my stuff roughly 5 projects, 2 shared libraries but you get quite fast at refactoring it once you’ve done it many times and the great thing is you can setup snapshot testing and you can avoid UI regression bugs leading from miss-refactored css to give you confidence to refactor at scale.