bundle less
npm install @unbundle/mvtbash
$ npx create-mvt-app
$ cd
$ npm install
$ npm run dev
`
If using Yarn:
`bash
$ yarn create mvt-app
$ cd
$ yarn
$ yarn dev
`
Browser Support
mvt requires native ES module imports during development. The production build also relies on dynamic imports for code-splitting (which can be polyfilled).
mvt assumes you are targeting modern browsers and therefore does not perform any compatibility-oriented code transforms by default. Technically, you _can_ add autoprefixer yourself using a PostCSS config file, or add necessary polyfills and post-processing steps to make your code work in legacy browsers - however that is not mvt's concern by design.
Features
- Bare Module Resolving
- Hot Module Replacement
- TypeScript
- CSS / JSON Importing
- Asset URL Handling
- PostCSS
- CSS Modules
- CSS Pre-processors
- JSX
- Production Build
mvt tries to mirror the default configuration in vue-cli as much as possible. If you've used vue-cli or other webpack-based boilerplates before, you should feel right at home. That said, do expect things to be different here and there.
$3
Native ES imports doesn't support bare module imports like
`js
import { createApp } from 'vue'
`
The above will throw an error by default. mvt detects such bare module imports in all served .js files and rewrites them with special paths like /@modules/vue. Under these special paths, mvt performs module resolution to locate the correct files on disk:
- vue has special handling: you don't need to install it since mvt will serve it by default. But if you want to use a specific version of vue (only supports Vue 3.x), you can install vue locally into node_modules and it will be preferred (@vue/compiler-sfc of the same version will also need to be installed).
- If a web_modules directory (generated by Snowpack) is present, we will try to locate it.
- Finally we will try resolving the module from node_modules, using the package's module entry if available.
$3
- *.vue files come with HMR out of the box.
- For *.js files, a simple HMR API is provided:
`js
import { foo } from './foo.js'
import { hot } from '@hmr'
foo()
// this code will be stripped out when building
if (__DEV__) {
hot.accept('./foo.js', (newFoo) => {
// the callback receives the updated './foo.js' module
newFoo.foo()
})
// Can also accept an array of dep modules:
hot.accept(['./foo.js', './bar.js'], ([newFooModule, newBarModule]) => {
// the callback receives the updated mdoules in an Array
})
}
`
Modules can also be self-accepting:
`js
import { hot } from '@hmr'
export const count = 1
// this code will be stripped out when building
if (__DEV__) {
hot.accept((newModule) => {
console.log('updated: count is now ', newModule.count)
})
}
`
Note that mvt's HMR does not actually swap the originally imported module: if an accepting module re-exports imports from a dep, then it is responsible for updating those re-exports (and these exports must be using let). In addition, importers up the chain from the accepting module will not be notified of the change.
This simplified HMR implementation is sufficient for most dev use cases, while allowing us to skip the expensive work of generating proxy modules.
$3
Starting with v0.11, mvt supports