-
-
Notifications
You must be signed in to change notification settings - Fork 72
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
experimental : postcss-custom-shorthands #647
experimental : postcss-custom-shorthands #647
Conversation
@@ -1,9 +1,8 @@ | |||
export const packageBabelPreset = [ | |||
['@babel/preset-env', { | |||
corejs: 3, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I had already fixed this in the v8
branch.
We don't have corejs
as a dependency.
This worked because we only wrote JS that didn't need any polyfills from corejs
.
css-tree
might require a polyfill for typed arrays. (these matches can have false positives)
Removing corejs
from our config is the right fix as we never actually had it in the first place.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed!
This is likely unimplementable : w3c/csswg-drafts#7879 (comment) |
{ | ||
"name": "@csstools/postcss-custom-shorthands-experimental", | ||
"description": "Research plugin for a Custom Shorthands proposal", | ||
"version": "1.0.0", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this be in the 0.0.x
realm?
So I like this a lot! Love the versions too I'm wondering a couple of things
|
Closing because it can not be implemented. Thank your for reviewing @Antonio-Laguna 🙇 |
see : w3c/csswg-drafts#7879
Notes :
This plugin introduces
css-tree
as a dependency.I am fine with having it as a workspace dependency but if this feature ever becomes a real thing I prefer writing our own syntax definition parser from scratch. I don't like the bloat of having all of
css-tree
for this single parser. see : https://www.w3.org/TR/css-properties-values-api-1/#parsing-syntaxThis package was quickly written and lacks sufficient test coverage and coding style is not ideal in places. This is fine for now I think, as we will end up trashing it later. Better to start from scratch if we ever build this for real.
Custom data in VSCode has this effect :
A real plugin would not have this feature as we would rely on editors to do this work themselves. But it is useful to get a glimpse of the real author experience.