feat: Replace parcel to vite

[TheSeally]

Feat #logux/logux#98

• add vite entry point (index.html):

For now vite supports only *.html entry points (vitejs/vite#1861), so I can't use uikit.pug as entry. To be honest, there are hacks on how to fix this, but it seemed to me that this is a less clear solution.
So I created index.html and moved the head part there so that only the layout remains in the pug template

• rename entry css file from *.sss extensions to *.css

Unfortunately vite is not support sugarss files for now. If I use these files in entry point it doesn't transform. I found extensions that vite supports for link tag.
Later I will create issue for adding sugarss extensions. But for now I decided that renaming files is not big problem, besides these files only contain import statements

• move service.js to public folder

By default vite transform all files imported from scripts even those that are used in new URL expression, except those that stored in public folder.
If moving is not acceptable, I can add an exception for this file in the vite configuration, but moving all files that do not need to be transformed to a separate directory seemed more clear solution to me (absolute paths must be used to import those files)

• add vite pug plugin:

I didn't find a template plugin for pug. Only this one, but it didn't work properly.
I have created simple plugin. To include pug template it uses <template> tag with data- attributes. This way the plugin syntax doesn't break the html semantics
Unfortunately now it does not support partial rendering on HMR. I think that full HMR support can be the next step if it is needed here

• change size-limit paths since vite uses assets folder for artifacts
• remove parcel and it artifacts

---

One more specific thing to vite is that it inlines assets smaller than 4kb by default. I didn't change this so some assets become inline.
@ai what do you think about this option? I can disable this feature

[ai]

rename entry css file from *.sss extensions to *.css

It will stop SugarSS syntax highlight. If we can’t use .sss extension, it is better to replace SugarSS to CSS.

vite-plugin-pug

Do you want to publish it to npm? We may need it in postcss.org and Vite ecosystem will be happy.

scripts/serve.js

Why do we need scripts/serve.js? Do we have some problem of why we can’t use vite CLI with Vite config?

I didn't change this so some assets become inline.

No problem, but can you give a list of inlined assets (and where they was inlined) to double-check?

[TheSeally]

It will stop SugarSS syntax highlight. If we can’t use .sss extension, it is better to replace SugarSS to CSS.

Sorry I haven't worked a lot with sugarss (and VS Code Extension is now unpublished). Does it only highlight code when all files have the same extension? If so, then I will rename all remaining style files (not just entry css with import expression)

Why do we need scripts/serve.js? Do we have some problem of why we can’t use vite CLI with Vite config?

No problem, I changed code (moved inline config to vite.config.js in root) to support vite config and use CLI

No problem, but can you give a list of inlined assets (and where they was inlined) to double-check?

For now there are two assets:

• apple.png. This asset inlined in dist/index.html
• kurbanistika.woff2. This asset inlined in dist/assets/index.[hash].css

Do you want to publish it to npm? We may need it in postcss.org and Vite ecosystem will be happy.

Yeah, I can publish it to npm, but I need a little time to prepare code for publishing. Should I publish it before merging this PR or I can do it in other PR?

[ai]

Sorry I haven't worked a lot with sugarss (and VS Code Extension is now unpublished). Does it only highlight code when all files have the same extension?

I mean that you renames common.sss to common.css, but you need to add ; to @import statements to make it correct CSS file.

apple.png. This asset inlined in dist/index.html

Nope, this asset is not popular (in many cases it will not be used). So inlining will make performance worse.

kurbanistika.woff2. This asset inlined in dist/assets/index.[hash].css

It is not really bad, but make CSS parsing slower.

Right now, font is requested in separated HTTP request and we use fast font parser.

If we will inline it, we must use slow CSS parser, than base64 decoder and then font parser again.

If we will be able to disable it, it will be nice.

Yeah, I can publish it to npm, but I need a little time to prepare code for publishing. Should I publish it before merging this PR or I can do it in other PR?

Sure, we can merge it now [when apple.png and import statement will be fixes] and move to npm later.

[TheSeally]

So maybe disable inlining assets at all?
As alternative I can move this files (apple.png and font) to public directory but this will interrupt all vite transformation for them (for example adding hash to filename)

I mean that you renames common.sss to common.css, but you need to add ;

Oh, my bad, didn't catch this

[ai]

So maybe disable inlining assets at all?

Yeap. We do not need it with preload and service worker.

[TheSeally]

I fixed css files, disable inlining and update vite config to support intellisense

When I move pug plugin to separate package I will replace it here and also update build in postcss.org

@ai thanks for review and explanations about parsers

[ai]

Great. Thanks for PR.

Just a small fix (to not forget to include it to postcss.org) 476cba2

[vitalybaev]

I've created a PR with SugarSS support in the Vite's repository yesterday. So, maybe we could use .sss files with Vite soon.