refactor: fix clippy warnings and use native cargo tests

[mrnossiom]

Hi 👋🏻

A quick list of the changes I've made:

• add a rust-toolchain.toml, pinning to nightlies is recommended.
• move the stylers crate to top level, removing the workspace and moving the tests to the default tests folder supported by cargo. That means that you can use cargo run to execute tests
• get rid of panics in code, switching to rust Result type. The errors are now reported to the user by expanding the macro to compile_error!(#err) which allows the compiler to finish his job and emit more error at once.
• use more idiomatic Rust here and there, fixing clippy warnings or using Rust knowledge.
• the large diff is due to removing Cargo.lock files in examples and for the library (here is the relevant Rust FAQ)
• remove what seems to be comments to help Copilot to generate functions 😉
• introduce a struct Class to replace rand_class(), working with a plain string was weird, you don't know if the dot is included in the class

What I want to do:

• add more internal comments for cleaning and easing the contributing process
• maybe add a CI workflow, but this would mean paying for GitHub Action. I don't know if they have plans for open source projects
• cleanup logic to make it more readable

@abishekatp Tell me if you don't like some of the changes I've made

[mrnossiom]

Is there a specific question classes are prefixed with l- or is this a random choice ?

[abishekatp]

@MrNossiom Thank you for contributing. I have also wanted to refactor the code for long time now and tried different approach in another branch. What you have done seems better than that. I will test these changes locally once and merge it.

• About that choice of prefix, At that time I was specifically developing this project for Leptos so prefixed with 'l-'

[mrnossiom]

I would love to see stylers being nightly-free, I know having access to features is great, but we could find a workaround, maybe under a flag... Anyway, I didn't understand fully what does the add_spaces functions does? Can you enlighten me?

[mrnossiom]

I am also going to clean examples, leaving only 3: demo (all stylers macros), trunk, leptos

[abishekatp]

I am also going to clean examples, leaving only 3: demo (all stylers macros), trunk, leptos

Yeah that would be nice.

[abishekatp]

I would love to see stylers being nightly-free, I know having access to features is great, but we could find a workaround, maybe under a flag... Anyway, I didn't understand fully what does the add_spaces functions does? Can you enlighten me?

First of all @MrNossiom I think you have done great work. I was going through your changes and it makes sense.

So about what you asked, We know that in the css selectors whitespace information is an important thing. This add_spaces function will check if there is some whitespace between current rust token and previous rust token using the span information and update the pre_line and pre_col variables for next check.

The another change that would be useful:

Note: This let start = span.unwrap().start(); uses the official proced_macro crate. Because of this we have to declare this crate as proc_macro crate in the Cargo.toml file. This creates a limitation that we can only export functionalities of this crate as macros.

Solution I thought of: We can extract both the style and style_sheet modules to the separate crate and just use them in the style macro crate.

@MrNossiom What do you think about this?

[abishekatp]

Currently I am not able to find some way of getting the span information so I am using this approach. If you think of some other way to retain the whitespace information of the css content then we can optimize this library like we discussed in this issue.

[abishekatp]

@MrNossiom Hi Sorry for taking so long. I have been working on fixing the above mentioned issue for some time. The good news finally I was able achieve it. But the bad news is those changes makes the rust workspace neccessary. So I don't think we will be able to merge this request directly. Will you be able to make these changes you have done here in the new implementation branch Or should I do it? If you are willing to make the changes in another branch please give me one or two days to finish that implementation.

[mrnossiom]

Hi @abishekatp, I may be less responsive since I'm on vacation but I would suggest that merging your new branch into mine would be simple. I can take care of resolving the conflicts. The changes I've made are already mergeable, I'll do another PR to complete this one.

[abishekatp]

Okan then I will merge that stylers_build branch with the main branch then you can resolve all the merge conflicts here. But please look into other branch changes if you get some time there I have extracted the css parsing logic from the proc_macro crate so that we can reuse that logic for both proc_macro and other use cases. Thank yoy. Enjoy the vacation:)

[mrnossiom]

I would have first merged mine, or merged your changes into this branch but you choose.

[abishekatp]

We can also merge your request but we have to keep the workspace structure of the project. Because it is needed by the new implementation where I have extracted stylers core logic into a separate crate and stylers macro as a separate crate. Can you make those changes in this branch?

[mrnossiom]

Done!

[abishekatp]

It looks good @MrNossiom I will merge it in this week.

[abishekatp]

Hi @MrNossiom sorry for disturbing again, I am trying to run these test cases using cargo test but it doesn't seem running test cases. Is there a specific way to run them?

[mrnossiom]

You were right, I forgot to move the tests when going back to a workspace.

[abishekatp]

You were right, I forgot to move the tests when going back to a workspace.

Yeah okay

[mrnossiom]

Thanks a lot 🥳

[abishekatp]

Thanks a lot 🥳

Actually Thanks to you @MrNossiom for your contribution(pardon me for taking this much time though 😂).