Open glenntws opened 2 years ago
First version didn't work, so after further investigation I think I found out why this whole Tailwind stuff is not working in Watch mode. The dirDependency messages are not relevant for any plugin as it seems (does someone know if the data get's used elsewhere? Without parsing dirDependency it stays empty anyways for my use case).
What's important though is the sourceText that get's passed into the plugins "sourceText" argument.
On first start, the unmodified source text get's passed in, i.e.
@tailwind base;
@tailwind components;
@tailwind utilities;
:host {
display: block;
}
After doing a change on the tsx though, the modified CSS for the components get's passed in (cached variant from previous build run)
This basically makes it impossible to adapt the CSS to include tailwind classes that were unused beforehand without completely restarting the compile process.
At least that's my interpretation. As I understood, the plugins transform
function is called by Stencil, and even though this makes somehow sense (CSS hasn't changed, so why bother?) this creates a problem, when we basically have all our "CSS" in the TSX files...
Suggestions?
New version adds an option to the config of the plugin:
The optional plugin alwaysParseNonCachedCss
allows the user to force the plugin to manually read a non-cached input version of each CSS. This prevents the plugin from reading a non-modified CSS, that was internally consumed and modified by a previous build pass.
I'm not 100% sure if this is the final solution. Are there other CSS plugins that could be executed in front of this plugin, where it would cause to ignore the previously made modifications (i.e. SASS?)
For the first run, this is fine, but I think the Stencil developers should provide us with an option that allows us to invalidate cached CSS files if other files were changed (maybe as a glob, or just an "invalidateCachedCssOnTsxChange" or something like that). That way, we would not have to do these kinds of workarounds.
I removed the whole parsing of "dependency" and "dirDependency" messages from PostCSS, since that apparently doesn't correlate with this whole problem after all and provides non used information.
FYI: Tested this change (properly this time ;) ) and it works fine with this configuration:
import { Config } from '@stencil/core';
import { reactOutputTarget as react } from '@stencil/react-output-target';
import { postcss } from '@stencil/postcss';
import tailwindcss from 'tailwindcss';
import autoprefixer from 'autoprefixer';
import purgecss from '@fullhuman/postcss-purgecss';
import cssnano from 'cssnano';
export const config: Config = {
plugins: [
postcss({
plugins: [
tailwindcss({
content: ['./src/**/*.{ts,tsx,html}'],
theme: {
extend: {},
},
plugins: []
}),
autoprefixer,
purgecss({
content: ["./src/**/*.tsx", "./src/**/*.css", "./src/index.html"],
defaultExtractor: content => content.match(/[A-Za-z0-9-_:/]+/g) || []
}),
cssnano()
],
alwaysParseNonCachedCss: true
})
],
...
};
@splitinfinities Any updates on this PR?
Hi @glenntws,
Not sure if you're still interested in this as it's been over a year, but if possible could you try out the 2.2.0
release?
It should be doing something similar to this PR (not passing the source through postcss multiple times) but without the config option.
https://www.npmjs.com/package/@stencil-community/postcss/v/2.2.0
This pull request is a solution to Issue #38.
dir-dependency
messages will be parsed and with the help of the glob package, globs will resolve to file lists parsable by Stencil.The parsing of
dir-dependency
messages happens in accordance with the recommendations set by the PostCSS guides.The change was tested in a Tailwind+Stencil integration, where JIt updates now work properly.