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

Add postprocess plugin set #60

Merged
merged 4 commits into from Aug 16, 2017

Conversation

alexlafroscia
Copy link
Contributor

@alexlafroscia alexlafroscia commented Jan 3, 2017

Adds a new option to provide a set of PostCSS plugins to run after concatenation has taken place. This is useful for plugins like postcss-sprites, which should be run later in the CSS pipeline.

Closes salsify/broccoli-css-modules#3

Todo

  • Unit tests for the new Broccoli plugin replaced by a dependency
  • Rebase from master
  • Smoke test to ensure the postprocess plugins are applied to the output file.

@dfreeman
Copy link
Member

dfreeman commented Jan 4, 2017

I probably won't have a chance to look at this deeply until this weekend, but thank you so much for taking this on!

@alexlafroscia
Copy link
Contributor Author

No problem 😄 we're just using my fork in our app right now and I can confirm it works as intended. I'm excited to get this finished and published, we've been using a fork of ember-css-modules for a long time and I'm stoked to be able to just track the latest from here on out.

Copy link
Member

@dfreeman dfreeman left a comment

Choose a reason for hiding this comment

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

A couple questions, but overall this is looking great — let me know if there's anything I can do to help out on the testing front.

@@ -24,8 +25,17 @@ OutputStylesPreprocessor.prototype.toTree = function(inputNode, inputPath, outpu

debug('concatenating module stylesheets: %o', concatOptions);

var parentOptions = options.registry.app.options || {};
var cssModulesOptions = parentOptions.cssModules || {};
var postprocessPlugins = cssModulesOptions.plugins && cssModulesOptions.plugins.postprocess;
Copy link
Member

Choose a reason for hiding this comment

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

You can call this.owner.getPlugins() to simplify this

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Oh awesome, I'll update that.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@dfreeman was this API removed between the initial PR and now? That method doesn't exist anymore

edit would the right thing now be getPostcssPlugins? That seems to do what I'm looking for

Copy link
Member

Choose a reason for hiding this comment

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

I think that's right—IIRC that was renamed to distinguish between ECM plugins and PostCSS plugins

map: {
inline: false,
annotation: false
}
Copy link
Member

Choose a reason for hiding this comment

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

Will this play nicely with user-specified source map settings?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Not sure -- @jasonmit ?

Copy link
Contributor

Choose a reason for hiding this comment

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

Unsure what is meant by user specific map settings, these: https://ember-cli.com/asset-compilation#source-maps ?

Copy link
Member

@dfreeman dfreeman Apr 12, 2017

Choose a reason for hiding this comment

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

Yep, we read that config and pass it along to broccoli-css-modules (as well as using it when concatenating everything together)

package.json Outdated
@@ -24,6 +24,7 @@
},
"homepage": "https://github.com/salsify/ember-css-modules#readme",
"devDependencies": {
"broccoli-persistent-filter": "^1.2.11",
Copy link
Member

Choose a reason for hiding this comment

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

This should be in dependencies, right?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Hmm, probably. @jasonmit ?

Copy link
Contributor

Choose a reason for hiding this comment

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

Yes, should be moved

@alexlafroscia
Copy link
Contributor Author

Sorry this got away from me @dfreeman. If you know of a good way to do the smoke test for the postprocess set, setting that up would be extremely helpful. I'll handle the unit test for the broccoli plugin tonight to make sure that it works right.

rondale-sc pushed a commit to rondale-sc/ember-css-modules that referenced this pull request Mar 22, 2017
This is intended only for short term use / testing.  Will be unnecessary
once salsify#60 and broccoli-css-modules#4 are merged
@FransTwisk
Copy link

I hope this will be merged eventually. Very useful.

@alexlafroscia
Copy link
Contributor Author

Yeah, sorry about that. getting back to the tests just hasn't been a priority but should be. It won't be this weekend, but maybe the weekend after I'll be able to carve out some time

@FransTwisk
Copy link

Any updates on this?

@alexlafroscia
Copy link
Contributor Author

Yeah, so... No. But I really need to do this, since our app requires this PR and we'd really like to get on the official release (and PostCSS 6). My holdup is mostly just not really knowing how to test Broccoli stuff. Maybe @jasonmit has some insight there?

@dfreeman
Copy link
Member

For testing Broccoli stuff I've found broccoli-fixture to be super helpful — we use it over in broccoli-css-modules, though that project is still on Mocha instead of QUnit for its tests.

@alexlafroscia
Copy link
Contributor Author

Cool, I'll definitely check into that. First step is rebasing, since it's been so long since this PR was made 😅 but it's on my list to check this out this weekend since we really want to get our app off of PostCSS 5 and onto 6.

@alexlafroscia
Copy link
Contributor Author

alexlafroscia commented Jul 23, 2017

@dfreeman after checking out the new Plugin system you have added since this PR started (which is awesome, by the way!) I think this could actually be added as a plugin instead. Would you prefer that to adding it to the default add-on? I feel like the use-cases for this are actually pretty slim, and like the idea of allowing people to opt in to running the code by installing an additional add-on.

I think it could look a lot like the Sass plugin, just running arbitrary PostCSS plugins that the user can configure instead of enabling Sass.

edit after looking more... maybe that's not the right approach. I'm going to keep working on this as a PR.

@dfreeman
Copy link
Member

@alexlafroscia I think framing this as a plugin is an interesting idea — as it sounds like you've discovered, the current plugin API is lacking the hook you'd need, but I could easily imagine adding broccoli-based plugin methods for manipulating the tree pre-CSS-modules, post-CSS-modules and post-concatenation.

Your plugin would just implement that third hook, taking the concatenated file and performing an additional round of PostCSS processing on it. What do you think of an approach like that?

@alexlafroscia
Copy link
Contributor Author

Yeah, that sounds interesting! I'm fine doing it that way.

My first commit here (I squashed all the previous commits together to make it easier to rebase onto master) implements things basically the same way that the initial PR did. The only major difference is that instead of including the Broccoli plugin that will get run on post-process as part of this repo, I found a separate one that was built on the same broccoli-persistent-filter that was already tested, and used that instead.

@dfreeman
Copy link
Member

Given how lightweight this wound up being, I'm not opposed to landing it as core functionality, as long as we can get some kind of smoke test in place in one of the dummy app/addons to prevent regressions.

Regardless, it does feel like plugins should be able to implement something like this, but I can save tackling that for another day :)

@alexlafroscia
Copy link
Contributor Author

Working on that test now :) Just trying to look through the existing tests to get an idea of how I can verify that the postprocess plugins are actually run.

@alexlafroscia
Copy link
Contributor Author

@dfreeman what would you be looking for for a "smoke test" here? I'm not sure how to verify that those plugins were run other than setting up a dummy app with a plugin and checking to see if the output CSS was transformed. Would that do? Maybe using ember-cli-addon-tests?

@dfreeman
Copy link
Member

I think the simplest thing to do would be to add a component to the dummy app whose styles.css relies on something you configure as a postprocess plugin. Then you can just throw together an integration test to verify the right style actually gets applied, similar to how we verify that imports resolve correctly.

@alexlafroscia
Copy link
Contributor Author

👍 great idea. I'll do that!

I made a PR there that enables the same style of plugin definition that
the `before` and `after` hooks support to make `postprocess` consistent
with them. This bumps the version of the dependency to include that
change.
@alexlafroscia
Copy link
Contributor Author

alexlafroscia commented Jul 28, 2017

No idea if I did that right... I'm on a new laptop and was having trouble getting the tests running locally. I'm going to let CI tell me if that worked.

@alexlafroscia
Copy link
Contributor Author

@dfreeman just wanted to bump this... we'd love to get off of my old fork and onto the latest version, but we need this to land first!

@dfreeman
Copy link
Member

Oops, sorry for the delay @alexlafroscia! I meant to look at this before I left for vacation and totally lost track. I should have some time in the next day or so to take a look.

@dfreeman dfreeman merged commit 95fb7e0 into salsify:master Aug 16, 2017
@alexlafroscia
Copy link
Contributor Author

No problem! Thanks for merging, glad to get this landed after so long (my fault, not yours) 😅

@dfreeman
Copy link
Member

This is now released in 0.7.3 — thanks again @alexlafroscia! 🎉

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