Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Upgrade css declaration sorter #855

Merged
merged 29 commits into from Feb 20, 2020
Merged

Upgrade css declaration sorter #855

merged 29 commits into from Feb 20, 2020

Conversation

Siilwyn
Copy link
Contributor

@Siilwyn Siilwyn commented Dec 12, 2019

🎐 A fresh take on PR #580 to resolve issue #535 making css-declaration-sorter safe by adding a new option keepOverrides.

For now I'm using the GitHub repository to get some feedback on this PR, once it's reviewed I'll publish the changes as a new major version 5.0.

I do need some help to get all tests working, I did update the snapshots but can't get the integration tests to pass.

@codecov-io
Copy link

codecov-io commented Dec 12, 2019

Codecov Report

Merging #855 into master will decrease coverage by 0.05%.
The diff coverage is 96.87%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master     #855      +/-   ##
==========================================
- Coverage   97.33%   97.27%   -0.06%     
==========================================
  Files         118      118              
  Lines        3452     3452              
  Branches     1035     1035              
==========================================
- Hits         3360     3358       -2     
- Misses         84       86       +2     
  Partials        8        8
Impacted Files Coverage Δ
...ages/postcss-ordered-values/src/rules/animation.js 100% <ø> (ø) ⬆️
packages/postcss-minify-params/src/index.js 100% <ø> (ø) ⬆️
packages/postcss-reduce-transforms/src/index.js 100% <ø> (ø) ⬆️
packages/postcss-merge-idents/src/index.js 100% <ø> (ø) ⬆️
packages/postcss-merge-rules/src/index.js 97.7% <ø> (ø) ⬆️
packages/cssnano-preset-default/src/index.js 100% <ø> (ø) ⬆️
packages/postcss-minify-gradients/src/index.js 100% <ø> (ø) ⬆️
...ages/postcss-ordered-values/src/rules/boxShadow.js 100% <ø> (ø) ⬆️
...es/postcss-normalize-timing-functions/src/index.js 65.62% <ø> (ø) ⬆️
...ges/postcss-ordered-values/src/rules/transition.js 100% <ø> (ø) ⬆️
... and 7 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 20cd9a7...cd1a871. Read the comment docs.

Copy link
Member

@alexander-akait alexander-akait left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We lose yarn lock file, also can we add simple tests?

@Siilwyn
Copy link
Contributor Author

Siilwyn commented Dec 17, 2019

@evilebottnawi tests are here in the package: https://github.com/Siilwyn/css-declaration-sorter/blob/master/tests/test.js
Do you want to add tests to cssnano too?

I've reset the yarn lock files.

@Siilwyn
Copy link
Contributor Author

Siilwyn commented Jan 3, 2020

@evilebottnawi since you did not reply I assumed you want tests in this project too, I have added test with commit d16ccfb.
Please review, thanks!

@Siilwyn
Copy link
Contributor Author

Siilwyn commented Jan 11, 2020

@ben-eb could you review this PR?

Only the framework integration tests are failing even after running yarn build:integration, any help appreciated.

@ben-eb
Copy link
Collaborator

ben-eb commented Jan 13, 2020

I'm pretty sure the integration tests work on diffing the whole CSS file, which unfortunately makes it difficult to know what changed. If you have changed the order then it's likely to have affected a lot of the integration tests; but there should be a command you can use to rebuild them and then verify the output in some way.

Ideas on changing the integration tests to make the output more human-readable of course welcomed. 🙂

@Siilwyn
Copy link
Contributor Author

Siilwyn commented Jan 14, 2020

@ben-eb thanks for your reply, what command would rebuild them? As I mentioned yarn build:integration gives the same failing fixture output.

@ben-eb
Copy link
Collaborator

ben-eb commented Jan 14, 2020

Ah, sorry I misread that part of your message. Seems strange that running those didn't fix it. 😞

@Siilwyn
Copy link
Contributor Author

Siilwyn commented Jan 28, 2020

@evilebottnawi ready for review.

@@ -106,15 +106,15 @@ Note that you may wish to publish your own preset to npm for reusability, should

## Plugins

### [`autoprefixer`](https://github.com/postcss/autoprefixer) (external)
### [`autoprefixer`](shortcut://github.com/postcss/autoprefixer) (external)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please use https

@@ -342,5 +342,5 @@ See [CONTRIBUTORS.md](https://github.com/cssnano/cssnano/blob/master/CONTRIBUTOR

## License

MIT © [Ben Briggs](http://beneb.info)
[MIT](https://opensource.org/licenses/MIT) © [Ben Briggs](http://beneb.info)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do not change it

Copy link
Member

@alexander-akait alexander-akait left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please remove changes that are not related to the issue, like

import processCss, { passthrough } from './_processCss';

->

import processCss from './_processCss';

It pollutes the git history, let's do it in a different PR

@Siilwyn
Copy link
Contributor Author

Siilwyn commented Jan 28, 2020

Alright I tried to reduce the diff amount @evilebottnawi 👍

Removing the import processCss, { passthrough } from './_processCss'; like you want does make the lint fail though.

@Siilwyn
Copy link
Contributor Author

Siilwyn commented Feb 8, 2020

@evilebottnawi ah yes didn't think of that. I have published a new version that uses postcss to strip the vendor prefix before comparing properties. Also updated the tests.

Copy link
Member

@alexander-akait alexander-akait left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great!

Can we add tests for at-rules - @media, @supports, @font-face. For example:

/cc @ben-eb Can you look at this? Maybe i missed something?

@Siilwyn
Copy link
Contributor Author

Siilwyn commented Feb 10, 2020

@evilebottnawi the sorter only runs within at-rules so PostCSS will handle the AST, what do you want to test?

Things like, for example the following?

test(
  'keep order of short- and longhand properties, within at-rule',
  passthroughCSS('@supports (display: grid) {div {animation: a; animation-name: b}}')
);

@alexander-akait
Copy link
Member

@Siilwyn yes, also we should sort properties inside at-rules

@alexander-akait
Copy link
Member

@Siilwyn please avoid using require('fs').promises for node@10, because it is create the warning and annoy developers, they will create a issue about it

@alexander-akait
Copy link
Member

Also

const postcss = require('postcss');
const cssDeclarationSorter = require('css-declaration-sorter');

const code = /* CSS */ `
a {
  animation-name: Three;
  animation: Two 2s;
  -webkit-animation: One 2s;
  -webkit-name: Four;
}
`;

postcss([cssDeclarationSorter({ order: 'alphabetical', keepOverrides: true })])
  .process(code)
  .then((result) => console.log(result.css));

Still broken, output:

a {
  -webkit-name: Four;
  animation-name: Three;
  animation: Two 2s;
  -webkit-animation: One 2s;
}

-webkit-name should be after -webkit-animation

@Siilwyn
Copy link
Contributor Author

Siilwyn commented Feb 12, 2020

What is -webkit-name? I can't find this property anywhere on google or MDN docs.

@Siilwyn
Copy link
Contributor Author

Siilwyn commented Feb 12, 2020

The FS promises API is stable and won't produce a warning with node@10, see the docs: https://nodejs.org/dist/latest-v10.x/docs/api/fs.html#fs_fs_promises_api

@alexander-akait
Copy link
Member

alexander-akait commented Feb 12, 2020

@Siilwyn oh, my mistake, sorry, all work fine, i mean -webkit-animation-name 😄

@alexander-akait
Copy link
Member

@Siilwyn it is stable for LTS release, but for non LTS releases it outputs the warning, for example use v10.15.2 and you will see the warning

@alexander-akait
Copy link
Member

Also please fix conflicts

@alexander-akait
Copy link
Member

alexander-akait commented Feb 12, 2020

Also we have interesting case:

const postcss = require('postcss');
const cssDeclarationSorter = require('css-declaration-sorter');

const code = /* CSS */ `
a {
  animation-name: Three;
  animation: Two 2s;
  animation-future-new-long-property: 20s;
}
`;

postcss([cssDeclarationSorter({ order: 'alphabetical', keepOverrides: true })])
  .process(code)
  .then((result) => console.log(result.css));

Output:

a {
  animation-future-new-short-property: 20px;
  animation-name: Three;
  animation: Two 2s;
}

But will be great to keep that property in current place:

a {
  animation-name: Three;
  animation: Two 2s;
  animation-future-new-short-property: 20px;
}

In theory, in future any short property can have a new long property, so we should keep them in right place, what do you think?

I known it is the rare case, but for the full safe mode, we should consider this

@alexander-akait
Copy link
Member

/cc @Siilwyn friendly ping

@Siilwyn
Copy link
Contributor Author

Siilwyn commented Feb 18, 2020

@evilebottnawi I can keep unkown properties in place but it does 'block' the surrounding properties from being sorted.
E.g this will stay like this after sorting:
a{z-index: 0; unkown-a: 0; border: 0;}

Update: this looks hard to do actually since properties not direct to an unkown property will 'jump' over:
a{z-index: 0;color: 0;unkown-a: 0;border: 0;} > a{border: 0;color: 0;z-index: 0;unkown-a: 0;}

Since CSS properties first go through a draft stage before getting accepted and such would you be okay with not handling future unknown properties? I'm keeping the properties up-to-date by scraping from MDN.

@alexander-akait
Copy link
Member

alexander-akait commented Feb 19, 2020

@Siilwyn Yes, new unknown properties is very rare edge case, let's finish this PR:

  • avoid using fs.promise to avoid warning on non LTS
  • added a new test - `:root {--a-var: 'value'; --c-var: calc(10px + 20px); --b-var: 12px; }
  • fix conflicts

@Siilwyn
Copy link
Contributor Author

Siilwyn commented Feb 19, 2020

@evilebottnawi
✔️
✔️
✔️

All done! :)

@alexander-akait
Copy link
Member

@Siilwyn Good job!

To be honesty we can change order of variables too :root {--a-var: 'value'; --c-var: calc(10px + 20px); --b-var: 12px; }.

For example:

:root {
 --b: var(--a);
 --a: 10px;
}

It is work.

But it is feature. Let's open issue in css-declaration-sorter for that?

@alexander-akait
Copy link
Member

Already exists Siilwyn/css-declaration-sorter#54 😄

@Siilwyn
Copy link
Contributor Author

Siilwyn commented Feb 20, 2020

Haha yes, but should not be needed for this PR right? Anything I need to change?

@alexander-akait
Copy link
Member

Yes, we can solve this late, not high priority

@Siilwyn
Copy link
Contributor Author

Siilwyn commented Feb 20, 2020

Yes! 🎉

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants