This is the first day of my participation in the August Text Challenge.More challenges in August

background

After vue3 was upgraded in the new project, vuE-CLI&WebPack was naturally replaced with Vite. I have to say that Vite is really delicious, not only the compilation speed is just right, but also has better support in vue3’s new features.

However, there were some problems in the development process

After seeing the viet-plugin-pages plug-in, I suddenly saw something like this:

import routes from "virtual:generated-pages";
Copy the code

In fact, when using many vite plug-ins, there is a usage in the reference like this:

import xxx from "virtual:xxx";
Copy the code

If virtual: XXX is not a package on NPM, what is it?

Importing virtual Files

After looking at the documentation of Vite, I realized that this is an import virtual file function, it can generate a virtual file for you to import.

Introducing a virtual file in the Plugin API of the Vite documentation is mentioned in the section that allows you to import a virtual file that does not exist but is generated temporarily from code.

This is done through the plugin of Vite, which means that the corresponding virtual files are generated in the NodeJS environment

Vite-plugin-pages is realized through this function, he first traverses the corresponding page directory during compilation, and dynamically generates the corresponding routing table according to the naming rules of directory structure and file name, so as to complete the good interaction between the local directory structure and dynamic routing.

There is a dynamic routing feature in NUxT as well, but it is not introduced in a virtual way, dynamically modifying the WebPack configuration before the project starts, using definePlugin to pass the routing table to the front-end code.

By introducing the virtual file feature, we eliminate the need to pass the corresponding data to the front-end code by passing modified constants.

Virtual import can do more than just pass constants, since it introduces a virtual JS file, which means we can also dynamically generate functions and code logic in it.

example

Such as, for example, can automatically import need in the generated code file, and then return a function, through the function before using the imported file, so that we don’t need to import these files in the actual use, by returning the virtual file exported functions we can directly use the original file to import.

import a from 'a-module'
import b from 'b-module'.import z from 'z-module'

constmodules = {a,b,... ,z}export default useModule(name){
    return modules[name]
}
Copy the code

Previously used 👇

import a from 'a-module'
import b from 'b-module'.import z from 'z-module a() b() c()Copy the code

Now use 👇

import useModule from 'virtual:xxx'

const a = useModule('a')
const b = useModule('b')
const c = useModule('c')
Copy the code

Of course this is just a simple example of whether you can use your imagination more or function more first

The document

Let’s go back to the documentation and see how the functionality is implemented?

Examples given in the document are as follows:

export default function myPlugin() {
  const virtualFileId = '@my-virtual-file'  

  return {
    name: 'my-plugin'.// Yes, will be displayed in warning and error
    resolveId(id) {
      if (id === virtualFileId) {
        return virtualFileId
      }
    },
    load(id) {
      if (id === virtualFileId) {
        return `export const msg = "from virtual file"`}}}}Copy the code

There are three key points:

  • VirtualFileId: indicates the virtual file name to be imported
  • ResolveId (ID): checks whether the virtual file name needs to be resolved
  • Load (ID): Returns the code string for the corresponding virtual import file

It can be seen that the returned code is returned as a string. We can easily construct the code string that needs to be returned through template concatenation or template translation.

Typescript support

However, it is important to note that the virtual file import returns JS code, not TS code, and the code is dynamically generated. This means that we will encounter situations where there is no type support in TS

If your code structure is defined, generate the corresponding D. ts definition file in advance. You can then load the corresponding definition file by configuring compileroptions. types in tsconfig. If the code structure is dynamic, you need to dynamically generate the corresponding D.ts file and write it into the project.

declare module 'virtual:xxx'{... }Copy the code

conclusion

It can not only let the front-end code can interact with the compilation environment, but also can dynamically generate code to achieve some previously not so convenient to implement functions, and the specific implementation of the development is very simple, are you ready to use in your plug-in?

Above is some personal learning experience and summary, thanks for reading!

If you feel this article is helpful to your words might as well 🍉 attention + like + favorites + comments + forward 🍉 support yo ~~😛