feat: compile scripts

[acesyde]

Description

• Add script compilation support
• Bypassing cache with --no-cache
• Add cleanup command

Fixes # (issue)

28

Type of change

• [ ] Bug fix (non-breaking change which fixes an issue)
• [x] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist

• [ ] I have performed a self-review of my code
• [ ] I have added tests that prove my fix is effective or that my feature works
• [ ] I have made corresponding changes to the documentation
• [ ] I have commented my code, particularly in hard-to-understand areas
• [ ] New and existing unit tests pass locally with my changes
• [x] I did test corresponding changes on Windows
• [ ] I did test corresponding changes on Linux
• [ ] I did test corresponding changes on Mac

[acesyde]

Todo :

• Code review
• Unit tests
• Documentation
• Better error handling
• Many tests !!!!

[alirezanet]

Awesome! very good draft. It might need a little bit of refactoring and code splitting but generally, it looks good.

few suggestions:

I think we should consider a few things where we save the cache files:

1- The compiled CSX files should have an extension like SomeNameOrHash.sdll (feel free to suggest a better extension I'm not sure there is a standard for this or not) 2- To visually relate the compiled files to CSX files we can use the actual script file name with our custom extension and save the hash value to an attribute on that file. this way later on we could have an auto cleanup process. e.g linter.sdll <- linter.csx. (we can find the compiled DLLs using their name and validate them using the attribute)

These changes open the possibility to directly support compiled scripts later.

well done. 💐

[acesyde]

1- The compiled CSX files should have an extension like SomeNameOrHash.sdll (feel free to suggest a better extension I'm not sure there is a standard for this or not)

Hmm sdll is like snupkg, the s prefix means source in my brain and it's not the case here, why not just .csx.dll ?

2- To visually relate the compiled files to CSX files we can use the actual script file name with our custom extension and save the hash value to an attribute on that file. this way later on we could have an auto cleanup process. e.g linter.sdll <- linter.csx. (we can find the compiled DLLs using their name and validate them using the attribute)

Nice idea ❤️

Yes I'll split the compiler from the executor

[alirezanet]

Hmm sdll is like snupkg, the s prefix means source in my brain and it's not the case here, why not just .csx.dll ?

I suggested sdll as an example to get more ideas ... but the problem with something like .csx.dll is, windows don't see the first part and categorize this as a normal DLL, in other words, the .csx section is not part of the extension, its a file name suffix. hdll for example could be another option that stands for Husky DLL. Naming things is hard :)

[acesyde]

You're right 😄 , I suck at naming things, for the moment i'll use .sdll but before merging this PR we have time to find another extension or not

[acesyde]

@alirezanet I found an usefull compiler can be integrated without any modifications dotnet-script with caching engine 😲

{
         "name": "doc-generator",
         "group":"pre-commit",
         "command": "dotnet",
         "args": [
            "dotnet-script",
            ".husky/csx/doc-generator.csx"
         ]
      }

I think we can use this one instead of the embedded what do you think ?

[alirezanet]

@alirezanet I found an usefull compiler can be integrated without any modifications dotnet-script with caching engine 😲

{
         "name": "doc-generator",
         "group":"pre-commit",
         "command": "dotnet",
         "args": [
            "dotnet-script",
            ".husky/csx/doc-generator.csx"
         ]
      }

True, it exists but I've tried to support this feature internally because first, not everyone are familiar with these tools and second it is easier for users to use internal husky features without downloading and installing extra dependencies.

also, I don't think it has a good caching mechanism, It will cache the scripts temporarily for the second call but it doesn't keep cache files properly. (I didn't check it recently but in the past I had a lot of problems with its cache system)

I think we can use this one instead of the embedded what do you think?

We can't. simply because we don't have enough permissions to install other tools for the end-user and we should be independent to external tools.