by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • May 29 18:25

    ai on ose

    Try to fix Windows test (compare)

  • May 29 18:24

    ai on ose

    Clean yarn mentions (compare)

  • May 29 18:21

    ai on ose

    Move from yarn to npm to fix CI (compare)

  • May 29 18:15

    ai on ose

    Try to fix CI (compare)

  • May 29 18:13

    ai on ose

    Try to fix CI (compare)

  • May 29 18:12

    ai on ose

    (compare)

  • May 29 18:11

    ai on ose

    Try to fix CI (compare)

  • May 29 18:09

    ai on ose

    (compare)

  • May 29 18:07

    ai on ose

    Try to fix CI (compare)

  • May 29 18:05

    ai on ose

    Remove Node.js 6 and Node.js 8 … Visitor to postcss (#1245) * f… Remove Babel and 98 more (compare)

  • May 28 13:32
    cossssmin commented #1362
  • May 28 13:18
    jsbrain commented #1362
  • May 28 13:16
    ai closed #1362
  • May 28 13:16
    ai commented #1362
  • May 28 13:07
    jsbrain opened #1362
  • May 27 05:50
    saimakin commented on 5f85550
  • May 27 05:50
    saimakin commented on 5f85550
  • May 26 06:40
    emzoumpo commented #1360
  • May 26 02:14
    ai commented #1360
  • May 26 02:14

    ai on master

    Add plugin to list (#1361) Add… (compare)

Jonathan Neal
@jonathantneal
Yes, so you would still need some sort of listener for additions or subtractions from document.styleSheet. I’m not sure the performant technique for that.
Jonathan Neal
@jonathantneal
For instance, in svg4everybody, we did something (potentially horrendous) like this:
var live_svg_elements = document.getElementsByTagName(‘svg’)
var live_svg_elements_length = 0
var svg_timeout_func = function () {
  if (live_svg_elements_length !== live_svg_elements.length) {
    live_svg_elements_length = live_svg_elements.length

    for (var i = -1; ++i in live_svg_elements;) {
      var live_svg_element = live_svg_elements[i]

      if (!live_svg_element.__processed_by_svg4everybody) {
        live_svg_element.__processed_by_svg4everybody = true

        // ... polyfill ...
      }
    }
  }

  requestAnimationFrame(svg_timeout_func)
}

svg_timeout_func()
I always assumed everyone would hate it, and it would just thrash cpus, but that wasn’t really a complaint I saw a lot.
Given modern browsers, I think you could be as lazy as setting up a MutationObserver that checks document.styleSheet on every subtree modification.
Jonathan Neal
@jonathantneal

Oh, and to answer your other question, ! causes whatever follows it to be evaluated as an expression. If a function is evaluated as an expression, then I can immediately invoke it (e.g. I can run it).

Because I use ! it will happen to return the inverted boolean of whatever the function returns, (e.g. !function () { return true }() === false), but nobody will care or need that, so !function () {}() becomes a shorter way of writing void function () {}() or (function () {})().

Gavin McFarland
@limitlessloop
Ok cool, thanks for the explanation. I’ve never seen it before and I couldn’t google it because Google ignored the special character ! in my search.

For instance, in svg4everybody, we did something (potentially horrendous) like this:

var live_svg_elements = document.getElementsByTagName(‘svg’)
var live_svg_elements_length = 0
var svg_timeout_func = function () {
  if (live_svg_elements_length !== live_svg_elements.length) {
    live_svg_elements_length = live_svg_elements.length

    for (var i = -1; ++i in live_svg_elements;) {
      var live_svg_element = live_svg_elements[i]

      if (!live_svg_element.__processed_by_svg4everybody) {
        live_svg_element.__processed_by_svg4everybody = true

        // ... polyfill ...
      }
    }
  }

  requestAnimationFrame(svg_timeout_func)
}

svg_timeout_func()

Yeah this is where it starts to go beyond my comprehension. But I can appreciate the complexity of what you’re trying to do. I’d like to see more around the issue of reuse in media queries in the future. Seems like we spend so much time create CSS rules only to have to repeat them everytime we use a media query.

Gavin McFarland
@limitlessloop
Is anyone familiar with using fs.watch to watch for changes to a file to invoke re-processing css file with postcss? I am watching a config file for changes, the file change is detected, but the stylesheet does not show the new changes. I suspect it’s an issue for fs.readFile maybe not picking up the changes from the config file because it’s being imported by another file.
function processTailwindCSS() {
  fs.readFile(__dirname + "/styles/tailwind.css", (err, css) => {
    console.log("function ran");
    return postcss([tailwindcss(__dirname + "/tailwind.config.js")])
      .process(css, {
        from: __dirname + "/src/styles/tailwind.css",
        to: currentPath + "/" + config.output + "/styles.css"
      })
      .then(result => {
        fs.writeFile(
          currentPath + "/" + config.output + "styles.css",
          result.css,
          () => true
        );

        if (result.map) {
          fs.writeFile(
            currentPath + "/" + config.output + "styles.css.map",
            result.map,
            () => true
          );
        }
      });
  });
}

processTailwindCSS()

fs.watch(configPath, { recursive: true }, () => {
    processTailwindCSS()
  console.log("file changed");
});
Then this is the file postcss([tailwindcss(__dirname + "/tailwind.config.js")] uses:
var currentPath = process.cwd();

module.exports = {
  ...require(currentPath + "/tailwind.config.js"),
  ...require(__dirname + "/plugins")
};
...require(currentPath + "/tailwind.config.js”) is the file that’s actually changing
I can’t figure out where the problem is.
Gavin McFarland
@limitlessloop
I think it has something to do with the module being cached when it’s required, it’s not a PostCSS related issue. Sorry
06062002
@06062002
Hello
Michael
@MichaelGaile
hi
rajan-magar
@rajan-magar

Any tips ?

Best practice to start working on existing project via css
Evilebot Tnawi
@evilebottnawi
postcss-cli
Jonathan Neal
@jonathantneal
Can postcss-loader be configured to use certain plugins only if no postcss.config.js is detected?
Evilebot Tnawi
@evilebottnawi
@jonathantneal Can you provide example?
Jonathan Neal
@jonathantneal
Well, in Create React App and in Preact CLI, they don’t let you overide the included plugin configuration.
That’s annoying.
Jonathan Neal
@jonathantneal
@evilebottnawi, if you can see a better way to do this, please let me know. https://github.com/preactjs/preact-cli/pull/832/files
Evilebot Tnawi
@evilebottnawi
@jonathantneal hm, you can create postcss.something.config.js and use require/import, it is reduce lines in config or we can implement options like config: false what disable loading user defined configuration
Jonathan Neal
@jonathantneal
I’m not sure that gives me what I was looking for. I want to the configuration file plugins to win over postcss-loader. It’s almost like I want the loader option to be defaultPlugins, which would only be used if plugins could not be found in the configuration file.
Evilebot Tnawi
@evilebottnawi
@jonathantneal hm, some understand, you want merge plugins from postcss.config.js (if exists) with postcss-loader plugins options, right?
Jonathan Neal
@jonathantneal
Close. However, I do not want to merge both arrays of plugins.
It’s like this — configFilePlugins || someDefaultPlugins — use the configuration file plugins, but if they are not specified then use the default plugins.
@evilebottnawi, this allows the configuration file to override the plugins option in postcss-loader.
Evilebot Tnawi
@evilebottnawi
hm, it is works in other way? It should try to load config, it config not found use someDefaultPlugins
If plugins option for postcss-loader looks like this — { loader: 'postcss-loader', options: { plugins: [ autoprefixer({ overrideBrowserslist: browsers }) ] } } — then it will override the plugins option in postcss.config.js.
Jonathan Neal
@jonathantneal
Evilebot Tnawi
@evilebottnawi
yes, oh it is bug, we should use logic as you written above, @ai what do you think?
can you open issue in postcss-loader?
We should fix behavior and release major version with fix
Jonathan Neal
@jonathantneal
I’m not sure what I’m suggesting should be the default behavior. I just want the ability to override the loader plugins. It would be much easier if there were just another option to specify defaultPlugins.
Evilebot Tnawi
@evilebottnawi
why? you already have plugins option, logic should be:
  1. try to search and load user configuration
  2. if not found use plugins option
Jonathan Neal
@jonathantneal
Maybe. Hmm. I’d like to know what @ai thinks. :point_up:
Benedikt Gregor
@scsskid
Hi, I'm wondering about the features option, why do I have to (?) additionally set options likenesting-rules' : truewhen installing and require a plugin (like postcss-nestedor postcss-nesting
Jonathan Neal
@jonathantneal
Here is my PR to add support for postcss.config.js in Preact CLI, which will let us specify our own PostCSS plugins without overriding the core preact configuration. preactjs/preact-cli#832
Evilebot Tnawi
@evilebottnawi
@jonathantneal good workaround, but i think we should fix logic on postcss-loader side, can you open issue?
Jonathan Neal
@jonathantneal
I will open an issue. Thanks for reviewing the change. I hope the maintainers approve it!
Evilebot Tnawi
@evilebottnawi
i am maintainer of postcss-loader :smile:
Sam Smith
@smth

Hi. I've run into a problem a couple of times now. I'm hoping someone might be able to shed some light on it. This seems to only occur once the codebase gets large. I don't have a minimal example, but I'll describe what one might look like.

File A has multiple (postcss-advanced-variables) mixin definitions.
File B calls one of those mixins, and passes parameters.
File C, calls another.
File D (postcss-import) imports file A, file B, and file C, and gets outputted.

When the problem arises, changes to parameters in file C for example have no effect on the output from file D. It feels as though something is being cached somewhere, to the point that even deleting the mixin in file A has no effect on the output. At this point I would expect there to be an error, because I'm calling a mixin that doesn't exist, but all gulp processes appear to run fine, and I can continue to edit file B and see those changes reflected.

I don't understand what's happening here. Any ideas?

Sam Smith
@smth
I should add that I'm using postcss-custom-properties too.
Sam Smith
@smth
Stopping the Gulp process can result in the expected error. I would then expect at this point, if there was some caching responsible for the strange behaviour, it will now have been cleared. However, reinstating the mixin again results in an output with old values (values that no longer exist anywhere in the codebase).
Jonathan Neal
@jonathantneal
This is really random, @evilebottnawi, but I noticed a very reversion in style-loader that I’m not sure was intended.
Specifically, it was this work from last year: webpack-contrib/style-loader#219
That PR clearly shows that the work was approved and merged. However, the work was merged into a webpack-contrib:next branch on May 22, 2018.
Evilebot Tnawi
@evilebottnawi
oh, style-loader in my todo, but not near future