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
WIP: Add PostCSS's SugarSS recognition by default #1689
Conversation
@DoumanAsh Can you help me ? |
@Kompwu Well as far as I understand currently you'd need to register this extension to be recognized as CSS asset: const Bundler = require('parcel-bundler');
let bundler = new Bundler('input.js');
bundler.addAssetType('.sss', './assets/CSSAsset'); If I understand this API correctly(I'm currently decided to use plain CSS with nesting support |
@DoumanAsh Thanks, |
@Kompwu Sorry I'm not sure as I'm new to parcel myself |
@DeMoorJasper Can you merge it pls ? |
It would be nice if the sugarSS asset actually installed and configured postCSS for the user, this way it works |
@DeMoorJasper Ok, I'll try to approach with this suggestion. But what should we do if user already has config? |
@DoumanAsh You can probably load the PostCSS config and check for SugarSS and just forward it to CSS if it's already installed and configured I guess? |
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.
You should load the PostCSS
configuration and check for SugarSS
& transpile it to CSS
if it's already installed and configured.
If not, configure PostCSS
& SugarSS
& transpile it to CSS
.
I tried to give it a go by extending existing CSS asset, but it makes me think that it is rather difficult to do. The problem is not only to load postcss config, but there is also |
@DoumanAsh Do what you can and we'll help you with everything else. |
@DoumanAsh How's going? |
@Kompwu Sorry, I've been a bit busy lately, I'll try to resume working on it as soon as I have time |
Currently I have issue with PostCSS API usage as it seems to cause errors when I attempt to parse Though I did set I was thinking that I could parse SugarSSS into CSS and then rely on existing |
@DoumanAsh Any news ? |
@Kompwu Sorry, recently I'm busy with other things and didn't look into PostCSS |
@DoumanAsh How's going ? |
@Kompwu Sorry I'm not actively using parcel as of the moment and kinda busy so I'm not planning to resume work on it until need arise again. I don't mind someone to carry on, or leave issue open so that me or someone else could continue later on. |
@ai Hi, can you take a look ? |
src/assets/SSSAsset.js
Outdated
} | ||
|
||
parse(code) { | ||
let root = postcss.parse(code, {from: this.name, to: this.name, syntax: sugarss}); |
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.
syntax
=> parser
.
We need to set SugarSS only as input language (parser) and keep output language (stringifier) as default CSS
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 think I also tried it initially, but for some reason postcss still parsed code as if it was CSS
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 will try to run tests after Def Con
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 can try if you want.
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.
Yeap, it should be parser:
.
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.
So all that remains is to automate the configuration?
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.
Just locking this for merge untill this is finished
@DeMoorJasper Are you sure automating configuration is a good thing? |
@Kompwu We are not automating config, we're adding a default? I just thought it might be useful to actually have something with extension sugarSS be transpiled to css by default (it should still read the config and potentially even just pass along the sugarss file to postCSS without any transforms if it's configured). The rest of the PostCSS transforms will still apply as far as I know... |
@DoumanAsh Can you finish? |
@Kompwu To be honest I'm not sure why, but even when I place The current commit also makes |
How does it add it as a dependency, you could use localRequire, that's how it's supposed to be used. |
src/assets/SSSAsset.js
Outdated
} | ||
|
||
parse(code) { | ||
let root = postcss.parse(code, {from: this.name, to: this.name, parser: sugarss}); |
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.
let sugarss = await localRequire('sugarss')
src/assets/SSSAsset.js
Outdated
@@ -0,0 +1,35 @@ | |||
const postcss = require('postcss'); | |||
const sugarss = require('sugarss'); |
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 be a local require and a dev dependency for testing...
src/assets/SSSAsset.js
Outdated
} | ||
} | ||
|
||
class CSSAst { |
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.
Split this up into a seperate file, so both CSS and SugarSS Asset use it
src/transforms/postcss.js
Outdated
if (config.parser === undefined && asset.options.css_parser !== undefined) { | ||
const name = asset.options.css_parser; | ||
|
||
if (!(typeof name === "string")) throw "Internal Error: Invalid PostCSS parser type. Should be string"; |
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.
typeof name !== "string"
src/transforms/postcss.js
Outdated
|
||
if (!(typeof name === "string")) throw "Internal Error: Invalid PostCSS parser type. Should be string"; | ||
|
||
let parser = await localRequire(name, asset.name).catch(() => require(name)); |
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.
why does it catch with a require, that's what localRequire already does?
localRequire's should just throw if it fails, because require is just the same thing. (Unless you want to require something from inside parcel, but that should happen inside the transform not be a fallback as this could have unwanted side-effects)
src/assets/SSSAsset.js
Outdated
|
||
class SSSAsset extends CSSAsset { | ||
constructor(name, options) { | ||
options.css_parser = "sugarss"; |
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.
Why is this necessary?
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 wanted to propagate to transform
to automatically load parser, if it is necessary.
But not sure if it is good idea
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.
You already do a localRequire in transform so not sure why this is necessary at all.
Thanks for review, I applied majority of comments. I'm not sure though how to automate configuration for PostCSS though. My simple integration test is still failing me:
|
@@ -0,0 +1,18 @@ | |||
class CSSAst { |
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.
Rename the file to CSSAst, as js and html also have an ast...
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 was thinking that it would be better for future to have common source of asts?
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.
In the future every asset will have it's own package so it will be seperate anyways
} | ||
} | ||
|
||
module.exports.CSSAst = CSSAst; |
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.
Just make this the default export module.exports = CSSAst;
You could check if the postCSS config already has a sugarss transform setup and skip this transform entirely if it has. But in the test it probably shouldn't have any postCSS config. Otherwise you're basically just testing postCSS |
I've changed some stuff around and it should be working better now. You might want to cleanup and debug it a bit more as it's not actually working right now, and def not clean |
Gonna open up a new PR that bases of off this one, with fixed code |
Personally I find SugarSS is pretty nice simplified version of CSS syntax.
Since its addition is configured by setting corresponding parse in PostCSS's config, I wonder if it would be ok to add its extension by default?