Giter Site home page Giter Site logo

phoenix-ru / fervid Goto Github PK

View Code? Open in Web Editor NEW
332.0 6.0 6.0 9.84 MB

All-in-One Vue compiler written in Rust

Home Page: https://phoenix-ru.github.io/fervid/

License: Apache License 2.0

Rust 93.58% Vue 2.23% TypeScript 1.29% JavaScript 2.59% HTML 0.23% CSS 0.08%
compiler rust sfc vue3

fervid's People

Contributors

cijiugechu avatar dependabot[bot] avatar erkelost avatar phoenix-ru avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar

fervid's Issues

Provide LSP

Features I personally find very desirable:

  • auto-completion of tag names (regular html and using auto-imports from #24);
  • auto-completion of component attributes (VBind and VOn);
  • parse error reporting (HTML and JS/TS);
  • ...

Support auto-imports (components and symbols)

To avoid extra overhead of using unimport in js side, most of the component and directive resolutions can happen in the Rust side.

  • Research how unimport works on source code;
  • Research how unimport gathers the auto-import symbols (across source code and dependencies);
  • Research existing Node resolution libraries (import 'x' -> node_modules/path/to/x/index.js) in Rust;
  • Ensure we can support Lazy prefixed imports;
  • ... define other steps after research.

CI tests for ARM architecture

At the moment of writing, GitHub CI has no ARM-based hosted runners for public repositories.

As a follow-up from #12, we should add tests for ARM builds using QEMU.

Dedupe imports between `<script>` and `<script setup>`

Multi-target code generation

The possible compilation targets are (excluding DEV/PROD differences):

  • CSR;
  • SSR;
  • Vapor mode CSR;
  • TS library;
  • Possibly .d.ts generation;

The compiler needs to be able to efficiently support all the targets with some common layer and target-specific implementations.

Self-closing `/>` is invalid syntax on non-void HTML elements

Problem

The official Vue parser allows self-closing any HTML, but this is not valid by the spec. For example, this:

<template>
  <slot />
  <div class="bad" />
</template>

Using Nu HTML Checker by W3 results in a clear error:
image

The same happens when parsing with swc_html_parser. The error is being reported and the tag is not being closed:

InvalidHtml(NonVoidHtmlElementStartTagWithTrailingSolidus) <slot />

In addition, this also messes up the DOM Tree stack, which is the actual problem here.

Possible solution

All NonVoidHtmlElementStartTagWithTrailingSolidus should be considered a hard error.

Nice-to-have

It would also be nice to do RegEx search-replace as a utility in fervid.
Another option is to parse the HTML and only apply this fix to where the NonVoidHtmlElementStartTagWithTrailingSolidus problem is encountered.

Auto-imports for known `vue` symbols

Writing SFCs using the default JS compiler and https://github.com/unplugin/unplugin-auto-import produces not-so-optimal code.

Take this for example (playground):

<script setup>
const msg = ref('Hello World!')
</script>

<template>
  <h1>{{ msg }}</h1>
  <input v-model="msg" />
</template>

Correct binding type of msg cannot be properly inferred, which leads to compiler generating unref(msg), which in turn has runtime cost.
In addition to that, extra build step is needed to properly auto-import the ref.

A better approach would be to add a ref/computed/etc. vue-specific imports whenever their usage is detected. It is much cheaper and more beneficial to do so in the SFC compiler than in any other tool.

Steps:

  • Detect stray known symbols usage. This can happen during regular transform pass;
  • Inject non-prefixed imports (e.g. import { ref } from 'vue' instead of ref as _ref);
  • Respect user-defined imports (e.g. import { ref } from './custom-path' should not auto-import).

Infer `ref` and `computed` TypeScript types for smarter inlining

Situation

When using <script setup lang="ts"> we can make assumptions regarding binding types. For instance, we can confidently infer the types of bindings in this example:

<script setup lang="ts">
import { ref, computed } from 'vue'

const foo = ref('Hello')
const bar = ref(1)
const baz = computed<number>(() => bar.value * 2)
</script>

Proposal

fervid can trust the user's TypeScript setup to catch type errors. In the future, when stc is mature enough, it will be used for type inference and checking.

Knowing the binding TS type, we can further optimize the generation of Interpolations and SSR attributes:
const msg = ref('') // string

What Mode Current generation Proposal generation
{{ msg }} CSR _toDisplayString(msg.value) msg.value
{{ msg }} SSR _ssrInterpolate(msg.value) msg.value
:value="msg" SSR _ssrRenderAttr("value", msg.value) `value="${msg.value}"`

By having the knowledge of types we can omit unnecessary runtime checks and also ship less code.

Possible implementation

The transformer already detects Vue-specific symbols, such as ref and computed. We can extend the analysis to also visit the value (second priority) or the type annotations (first priority) and store this information along with the BindingTypes.

Considering the fact that TS types are complex and inference may not be trivial, the TS type must be an optional hint for the compiler.
When no such type can be inferred (or when outside TS), the compiler should fall back to default code generation.

Playground Preview

The project is wonderful.

In other to test and check it more conveniently, I'd like to request a playground, like this one.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.