-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
Workflow to use Tailwind in Vue components? #1
Comments
Amazing! Thanks for testing this Collin. Very cool that it just works, but I guess that sort of makes sense. Are we good to close this issue then? |
Yep! Closing. |
Hi @syropian, Can you show me your mix setup? I'm struggling with setting it up the way you suggested. My extracted Vue styles are just being inserted in between the output of preflight and utilities, but they're not being processed by PostCSS. |
@unxsist @lperiodbose Unfortunately you have to include |
So I can think of a few ways that we could make it possible to
I'm somewhat hesitant to solve this problem because I really don't want to encourage people to start using Tailwind solely as a library for building component classes, but if it's really a big problem for people then maybe we can try something. |
Is there a solution for this that Vue users not using Mix could implement? It looks like Update |
@alexsasharegan FYI you can use the
without including |
Thanks @r0skar, I updated my comment when I figured out that the broken |
@syropian I split my main SASS file into two: preflight with just In my
This isn't working. |
Since Tailwind 0.6.2 you can use However, this feature is disabled by default behind flags. It is also stated that this features may be changed or removed at any time without any regard for semantic versioning. If you still wish to enable it, add this to your tailwind config file: module.exports = {
// ...
experiments: {
shadowLookup: true
}
} You can then use your stylesheet like you normally would: // ./src/App.vue generated by Vue-CLI 3
// ...
<style lang="scss">
#app {
background-color: config('colors.yellow'); // eww
* {
color: config('colors.white');
}
@apply bg-black; // ahh better!
}
</style> |
@Wurielle Am I doing something wrong? What happens is styles webpack.mix.js mix.js('resources/js/app.js', 'public/js')
.sass('resources/sass/app.scss', 'public/css')
.options({
processCssUrls: false,
postCss: [tailwindcss('./tailwind.js')],
hmrOptions: {
host: '127.0.0.1',
port: 8080,
},
});
mix.webpackConfig({
module: {
rules: [
{
enforce: 'pre',
test: /\.(js|vue)$/,
loader: 'eslint-loader',
exclude: /node_modules/,
},
],
},
}); tailwind.js module.exports = {
// ...
options: {
prefix: '',
important: false,
separator: ':',
shadowLookup: true, // Should be official feature now
},
experiments: {
shadowLookup: true, // Added just in case
},
}; component.vue <style lang="scss" scoped>
.cart-bg {
@apply bg-black; // Just compiles into a string in css
}
.progress-bar {
&::-webkit-progress-bar {
@apply w-full; // Just compiles into a string in css
}
}
</style> UPDATE: Fixed by updating to unreleased |
Update functions-and-directives.blade.md
* WIP * WIP * remove warnings, everything builds now, tests are re-enabled * cleanup + use FxHashSet * remove timing related code * sort candidates to guarantee consistent order * update tests to reflect candidate sorting * sort candidates This is useful to do in Rust because we can do it in parallel. In Node we will still sort, but since most things should be sorted already it means that we don't have to spend too much time there. Doing this, resulted in ~4ms -> ~0.9ms for sorting in Node. * use String::from_utf8_unchecked because we already guaranteed valid utf8 when parsing This gave us a ~10% speedup * drop withAlpha on `theme` * only sort for Jest tests * Try to get a consistent criterion benchmark * WIP * WIP * WIP: batching + FxHashSet * WIP * use fastest algorithm so far * update input fixture with new changes from Tailwind UI I'll make sure to get proper fixtures in the benchmark folder soon so that we don't have to deal with this anymore. * add 1000 generated fixture files The idea behind these fixtures files is that they are generated based on the classNames used in our Tailwind UI project without "leaking" Tailwind UI. - The fixtures take random class combinations from Tailwind UI and mix the class attribute before it was generated. - The structure of the HTML is also generated. - For text I've used a UUID. - We can probably find a way to generate something good on the fly without checking these in but it will do for now. - We can also probably improve them by making them even more "real" in the future (by replacing the UUIDs with real data for example) Checking them in so that we all run the same benchmarks against the same code. * use checked in fixtures for benchmarks * use the middle X files to benchmark with * refactor * Pull in tracing * Work on better candidate parser * wip * WIP * cleanup * cargo clippy --fix * cleanup unused dependencies in the CLI * remove "simple" from benchmark What the frick does simple even mean? * Add test case for Ruby arrays `w[foo]` isn’t a valid candidate part anyway (but @[foo] is) so we can pick up the internal bits as a candidate. Not 100% sure if we want to do this but it seems sensible-ish * rename NAPI project * Simplify * bump @napi-rs/cli Co-authored-by: Amos Wenger <[email protected]> Co-authored-by: Jordan Pittman <[email protected]>
This will reduce the amount of candidates to handle. They would eventually be skipped anyway, but now we don't even have to re-parse (and hit a cache) at all.
A bit of a vague commit message, but this does a lot of things. I could split it up, but not sure if it's worth it. Instead, let's talk about it. While working on keeping track of comment locations I was running into some issues. Not the end of the world, but we could make things better. Paired with Jordan on this to rework the algorithm. The idea is that we now do multiple passes which is technically slower, but now we can work on separate units of work. - Step #1 is to prepare the at-rule. This means that rules with multiple selectors will be split in multiple nodes with the their own single selector. - Step #2 is to collect all the classes we want to create an `@utility` for. - Step #3 is to create a clone of the main `@layer utilities` for all the non-`@utility` leftover nodes (E.g.: rules with element and ID selectors). - Step #4 is to create a clone of the main `@layer utilities` node for every single `@utility <name>` we want to create. - Step #5 is to go over every clone, and eliminate everything that is not part of the `@utility` in question. So we can remove siblings (except for comments near it) and go up the chain. - Step #6 is now to go over the initial `@layer utilities` clone we set aside, and remove everything that's not part of any of the clones. - Step #7 is cleanup work, where empty nodes are removed, and rules with a selector of `&` are replaced by its children. This is done in a depth-first traversal instead of breadth first. Co-authored-by: Jordan Pittman <[email protected]>
A bit of a vague commit message, but this does a lot of things. I could split it up, but not sure if it's worth it. Instead, let's talk about it. While working on keeping track of comment locations I was running into some issues. Not the end of the world, but we could make things better. Paired with Jordan on this to rework the algorithm. The idea is that we now do multiple passes which is technically slower, but now we can work on separate units of work. - Step #1 is to prepare the at-rule. This means that rules with multiple selectors will be split in multiple nodes with the their own single selector. - Step #2 is to collect all the classes we want to create an `@utility` for. - Step #3 is to create a clone of the main `@layer utilities` for all the non-`@utility` leftover nodes (E.g.: rules with element and ID selectors). - Step #4 is to create a clone of the main `@layer utilities` node for every single `@utility <name>` we want to create. - Step #5 is to go over every clone, and eliminate everything that is not part of the `@utility` in question. So we can remove siblings (except for comments near it) and go up the chain. - Step #6 is now to go over the initial `@layer utilities` clone we set aside, and remove everything that's not part of any of the clones. - Step #7 is cleanup work, where empty nodes are removed, and rules with a selector of `&` are replaced by its children. This is done in a depth-first traversal instead of breadth first. Co-authored-by: Jordan Pittman <[email protected]>
A bit of a vague commit message, but this does a lot of things. I could split it up, but not sure if it's worth it. Instead, let's talk about it. While working on keeping track of comment locations I was running into some issues. Not the end of the world, but we could make things better. Paired with Jordan on this to rework the algorithm. The idea is that we now do multiple passes which is technically slower, but now we can work on separate units of work. - Step #1 is to prepare the at-rule. This means that rules with multiple selectors will be split in multiple nodes with the their own single selector. - Step #2 is to collect all the classes we want to create an `@utility` for. - Step #3 is to create a clone of the main `@layer utilities` for all the non-`@utility` leftover nodes (E.g.: rules with element and ID selectors). - Step #4 is to create a clone of the main `@layer utilities` node for every single `@utility <name>` we want to create. - Step #5 is to go over every clone, and eliminate everything that is not part of the `@utility` in question. So we can remove siblings (except for comments near it) and go up the chain. - Step #6 is now to go over the initial `@layer utilities` clone we set aside, and remove everything that's not part of any of the clones. - Step #7 is cleanup work, where empty nodes are removed, and rules with a selector of `&` are replaced by its children. This is done in a depth-first traversal instead of breadth first. Co-authored-by: Jordan Pittman <[email protected]>
A bit of a vague commit message, but this does a lot of things. I could split it up, but not sure if it's worth it. Instead, let's talk about it. While working on keeping track of comment locations I was running into some issues. Not the end of the world, but we could make things better. Paired with Jordan on this to rework the algorithm. The idea is that we now do multiple passes which is technically slower, but now we can work on separate units of work. - Step #1 is to prepare the at-rule. This means that rules with multiple selectors will be split in multiple nodes with the their own single selector. - Step #2 is to collect all the classes we want to create an `@utility` for. - Step #3 is to create a clone of the main `@layer utilities` for all the non-`@utility` leftover nodes (E.g.: rules with element and ID selectors). - Step #4 is to create a clone of the main `@layer utilities` node for every single `@utility <name>` we want to create. - Step #5 is to go over every clone, and eliminate everything that is not part of the `@utility` in question. So we can remove siblings (except for comments near it) and go up the chain. - Step #6 is now to go over the initial `@layer utilities` clone we set aside, and remove everything that's not part of any of the clones. - Step #7 is cleanup work, where empty nodes are removed, and rules with a selector of `&` are replaced by its children. This is done in a depth-first traversal instead of breadth first. Co-authored-by: Jordan Pittman <[email protected]>
A bit of a vague commit message, but this does a lot of things. I could split it up, but not sure if it's worth it. Instead, let's talk about it. While working on keeping track of comment locations I was running into some issues. Not the end of the world, but we could make things better. Paired with Jordan on this to rework the algorithm. The idea is that we now do multiple passes which is technically slower, but now we can work on separate units of work. - Step #1 is to prepare the at-rule. This means that rules with multiple selectors will be split in multiple nodes with the their own single selector. - Step #2 is to collect all the classes we want to create an `@utility` for. - Step #3 is to create a clone of the main `@layer utilities` for all the non-`@utility` leftover nodes (E.g.: rules with element and ID selectors). - Step #4 is to create a clone of the main `@layer utilities` node for every single `@utility <name>` we want to create. - Step #5 is to go over every clone, and eliminate everything that is not part of the `@utility` in question. So we can remove siblings (except for comments near it) and go up the chain. - Step #6 is now to go over the initial `@layer utilities` clone we set aside, and remove everything that's not part of any of the clones. - Step #7 is cleanup work, where empty nodes are removed, and rules with a selector of `&` are replaced by its children. This is done in a depth-first traversal instead of breadth first. Co-authored-by: Jordan Pittman <[email protected]>
A bit of a vague commit message, but this does a lot of things. I could split it up, but not sure if it's worth it. Instead, let's talk about it. While working on keeping track of comment locations I was running into some issues. Not the end of the world, but we could make things better. Paired with Jordan on this to rework the algorithm. The idea is that we now do multiple passes which is technically slower, but now we can work on separate units of work. - Step #1 is to prepare the at-rule. This means that rules with multiple selectors will be split in multiple nodes with the their own single selector. - Step #2 is to collect all the classes we want to create an `@utility` for. - Step #3 is to create a clone of the main `@layer utilities` for all the non-`@utility` leftover nodes (E.g.: rules with element and ID selectors). - Step #4 is to create a clone of the main `@layer utilities` node for every single `@utility <name>` we want to create. - Step #5 is to go over every clone, and eliminate everything that is not part of the `@utility` in question. So we can remove siblings (except for comments near it) and go up the chain. - Step #6 is now to go over the initial `@layer utilities` clone we set aside, and remove everything that's not part of any of the clones. - Step #7 is cleanup work, where empty nodes are removed, and rules with a selector of `&` are replaced by its children. This is done in a depth-first traversal instead of breadth first. Co-authored-by: Jordan Pittman <[email protected]>
A bit of a vague commit message, but this does a lot of things. I could split it up, but not sure if it's worth it. Instead, let's talk about it. While working on keeping track of comment locations I was running into some issues. Not the end of the world, but we could make things better. Paired with Jordan on this to rework the algorithm. The idea is that we now do multiple passes which is technically slower, but now we can work on separate units of work. - Step #1 is to prepare the at-rule. This means that rules with multiple selectors will be split in multiple nodes with the their own single selector. - Step #2 is to collect all the classes we want to create an `@utility` for. - Step #3 is to create a clone of the main `@layer utilities` for all the non-`@utility` leftover nodes (E.g.: rules with element and ID selectors). - Step #4 is to create a clone of the main `@layer utilities` node for every single `@utility <name>` we want to create. - Step #5 is to go over every clone, and eliminate everything that is not part of the `@utility` in question. So we can remove siblings (except for comments near it) and go up the chain. - Step #6 is now to go over the initial `@layer utilities` clone we set aside, and remove everything that's not part of any of the clones. - Step #7 is cleanup work, where empty nodes are removed, and rules with a selector of `&` are replaced by its children. This is done in a depth-first traversal instead of breadth first. Co-authored-by: Jordan Pittman <[email protected]>
Ah yes, the dreaded first issue! Fortunately more of a question/discussion point than anything.
Is there a best way to use Tailwind with Vue single file components? It would be really nice to keep those one-off styles or component styles inside Vue components themselves, but the tricky part is getting component CSS between the preflight and utilities lines.
The only thing I can think of is to have 2 files — The first file would just contain
@tailwind preflight;
, and the second would have@tailwind utilities;
+ any custom utilities users want. In Laravel Mix, if we use theextractVueStyles
option, that should extract the Vue component styles at the top of the second file, which is what we want. We could then use Mix'scombine()
function to join 'em together.Last I suppose we'd have to add Tailwind tovue-loader
's PostCSS options.Nevermind, all PostCSS plugins in Mix apply to Vue component styles as well, no need to do it manually. 👍
I haven't had a chance to actually test this approach but I figured I'd gather some thoughts in case there's a better way.
Edit Again: Ok! I tested the above approach and it seems to work great. My Vue styles get injected in the right spot, and I'm also able to successfully use Tailwind functions (
config
,@apply
, etc) inside my Vue components. 🎉The text was updated successfully, but these errors were encountered: