-
Notifications
You must be signed in to change notification settings - Fork 1
WIP: CSS Next Support and Prefixing #1 #4
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
base: main
Are you sure you want to change the base?
Conversation
| let filepath = path.relative(assetManager.referenceDir, input); | ||
| console.error(`compiling CSS ${repr(filepath)} for ${browsers.join(", ")}`); | ||
| plugins.push(postcssPresetEnv({ | ||
| stage: 2, // maybe a little too unstable? |
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'm not familiar with the CSS process, but the JavaScript experience suggests that combining volatile (i.e. not-yet-finalized) features in a single package/declaration/whatever is bound to be troublesome:
https://babeljs.io/blog/2018/07/27/removing-babels-stage-presets
(TLDR: What's stage 2 today might be different next month, both in terms of the set of features and their respective contracts. Thus volatile features need to be versioned independently.)
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'm discussing this in the above linked issue. I'm not sure what is the best approach yet. But I'm not sure it makes sense to choose features by their stage 🤔
|
I'm thinking about a different approach: The user configures this plugin like this: {
source: "...",
target: "...",
cssnext: true,
ignore: ["rem"],
polyfill: ["custom-properties"]
}With this configuration, we will throw an error whenever we encounter a feature that is not supported by one of the selected browsers (by your
This can be accomplished by:
So this is pretty straightforward and will probably result in a pretty nice workflow: You just start with no configuration except
What do you think, @FND ? |
|
I have a working prototype: let postcss = require('postcss')
let doiuse = require('doiuse')
let fs = require('fs')
let postcssCustomProperties = require('postcss-custom-properties')
let plugins = [
// first, do the import stuff (skipped in this prototype)
// then, add all transforms chosen by the user
postcssCustomProperties({
preserve: false
}),
// finally, run doiuse with the provided browsers and ignored
// features
doiuse({
browsers: ['ie >= 8'],
ignore: ['rem'],
onFeatureUsage: function(usageInfo) {
console.error(usageInfo.message)
}
})
]
fs.readFile('src/app.css', (err, css) => {
postcss(plugins)
.process(css, { from: 'src/app.css', to: 'dest/app.css' })
.then(result => {
fs.writeFile('dest/app.css', result.css, () => true)
})
})Tested with this CSS: :root {
--color: red;
}
.a {
font-size: 1rem;
color: var(--color);
}it runs without any warnings and produces: .a {
font-size: 1rem;
color: red;
}If you remove either the |
This PR adds support for converting cssnext to CSS that works in the browsers you specified. It uses postcss-preset-env to do that.
Open Questions:
cssnext? (equivalent toesnextforjs)?