Prevent reordering css imports

[IanVS]

Sometimes the order of my css imports matters, because it will effect the cascade. Is there a way I can prevent the sort algorithm from operating against my css files and making them alphabetical?

Or maybe there's a comment I can use to prevent reordering particular sections / files? For instance in my index.tsx file I need to import my global css file before my app component, again for the cascade. Prettier itself has no ranged-ignore comments, unfortunately. https://github.com/prettier/prettier/issues/5287

Thanks!

[blutorange]

@IanVS I made a general issue for side effect imports here #110, if I understand you correctly, might this also solve your issue if the PR gets accepted (without requiring manual ignore comments)? Since CSS importd like import "some-file.css" would be considered a side effect import?

[IanVS]

Awesome, yes I think that's a good solution to this issue, and an elegant one at that! 👍

[IanVS]

Hmmmm, I may have found a case where special-casing side-effect-only imports does not solve my issue, and that is when using css modules. For example:

// MyButton.tsx

import originalStyles from './originalButton.module.css';
import styles from './myButton.module.css';

This will still be re-arranged, thus breaking the css cascade. I think your PR is a good start, and gets 90% of the way to closing this issue, but maybe not all the way. For now, I might be able to work around this by a combination of composes in css modules and careful naming, but it would be nice if there was some kind of general-purpose explicit import ordering escape hatch.

[blutorange]

I must say I'm not familiar with CSS modules myself -- the import order really affects the outcome? That seems like quite an abuse of ESModules ; ) But in that case, perhaps it would be better to conside those *.css imports as non-applicable to sorting and never sort them. Possibly via new option unsortableImports or fixedImports, where you'd provide one or more RegExp? And then either

• treat those imports the same way as side-effect imports
• somehow modify the sort algorithm to preserve their relative order (not sure how, perhaps just place the imports at the top of their respective group?)

Option 1 might be better because that truly allows you to move the affected imports around and all other imports before and after those will always stay before and after.

But these are just my thoughts when I read your comment, perhaps somebody else has a better idea?

[fkrauthan]

Yeah having some way of defining some dependencies order would be great (without having them split into separate groups in case grouping is enabled). Maybe something as simple as having a comment for import lines like: // prettier-import-order: 0 and another one with // prettier-import-order: 1 and then the sorting logic will first sort based on that order number and within the same order number (or no order number defined) it uses the regular ABC sorting.

[IdanLevi]

Any news on this?

[blutorange]

Personally (my opinion, not the opinion of the the author(s) of this plugin) I think we should keep it as simple as possible. Having to add prettier or plugin specific comments to change the sorting order might be a last workaround, but it feels wrong to me -- it should "just work" without these magic comments.

Having to manually group you CSS imports into sort groups also feels like a chore and sounds pretty fragile when the content of these files changes. And I think we should also keep in mind that adding too many code style options is also kinda against the spirit of prettier.

So perhaps we can collect more uses cases CSS imports like import styles from './myButton.module.css';? Should these never be sorted because the order is important, or are there some cases when people want to sort them and some cases when people don't want them to be sorted?

If the former we could simply never sort CSS imports. If the latter, a simple option like sortCssImports might help?

[fkrauthan]

The problem is less import styles from './myButton.module.css'; but more global css imports like

import "bootstrap"; 
import "./myApp.css";

I guess you could enable a css pre-processor and create a single import "./global.css" that in return imports the css files in correct order. But would be great to be able to say bootstrap always comes before bootstrap-typeahead which always comes before ./myApp.css

[blutorange]

@fkrauthan These global CSS imports (I call them side effect imports) won't be sorted after this gets merged https://github.com/trivago/prettier-plugin-sort-imports/pull/111 So they stay the way the user sorted them. Or should they be sorted in a custom order?

[fkrauthan]

Interesting. Do they still get grouped (based on my grouping rules) or will they just stay wherever they are?

[blutorange]

The idea was that these imports that don't import any symbol, so their only purpose can be a side effects. And since we don't know how these side effects interact, they just stay where they are. So the user can sort them however they want and the plugin keeps that order.

For now there should be no distinction between .js / .css etc. imports. So it should also preseve the order for these CSS imports. Perhaps css imports need a special treatment?

[IdanLevi]

Personally (my opinion, not the opinion of the the author(s) of this plugin) I think we should keep it as simple as possible. Having to add prettier or plugin specific comments to change the sorting order might be a last workaround, but it feels wrong to me -- it should "just work" without these magic comments.

Having to manually group you CSS imports into sort groups also feels like a chore and sounds pretty fragile when the content of these files changes. And I think we should also keep in mind that adding too many code style options is also kinda against the spirit of prettier.

So perhaps we can collect more uses cases CSS imports like import styles from './myButton.module.css';? Should these never be sorted because the order is important, or are there some cases when people want to sort them and some cases when people don't want them to be sorted?

If the former we could simply never sort CSS imports. If the latter, a simple option like sortCssImports might help?

I think a 'sortCssImports' option would be great.

[IanVS]

I think a 'sortCssImports' option would be great.

What would be the use case for wanting these to be sorted, thus changing the cascade of the resulting styles? That feels like a footgun to me.

[IdanLevi]

I think a 'sortCssImports' option would be great.

What would be the use case for wanting these to be sorted, thus changing the cascade of the resulting styles? That feels like a footgun to me.

Using React + styled-components package, when most projects have just 1 general css at App level, and other rare imports of css are side-effect imports required by a npm package, which usually don't need special ordering.

[adroste]

Wow, I can't believe that such a crucial thing is broken. Besides, this package just ignores the // prettier-ignore comment (see #26 ). So it's not even an option to just disable the sorting behaviour in files where order of imports matter. The sort-imports plugin for VSCode (https://marketplace.visualstudio.com/items?itemName=amatiasq.sort-imports) simply does not change the order of css imports.

Edit: This alternative plugin (https://github.com/simonhaenisch/prettier-plugin-organize-imports) is able to prevent reordering in critical situations with the comment // organize-imports-ignore. Not perfect but ok for the few files where order matters.

[IanVS]

@adroste, I also agree this is important, enough that I published a fork of this project that includes https://github.com/trivago/prettier-plugin-sort-imports/pull/111, so that side-effect imports are not reordered. You can find that fork at https://www.npmjs.com/package/@ianvs/prettier-plugin-sort-imports, in case it's useful.

[sam3k]

This is an awesome plugin but should CSS imports get sorted among themselves? This is bound to break the C in CSS rather often. 😄

[IanVS]

The maintainers here have said this kind of change would be out of scope for this plugin, so I'll close the issue.