vuejs / vue-component-compiler Goto Github PK

[email protected] uses an old babel that references a deprecated [email protected].

[email protected] does not depend on core-js, which is awesome.

What's the plans on getting this configured as a grunt task? Not sure how one would re-code this to handle the conversations as a grunt task - love to get your help here.

jspm.io

I imagine there will be users who don't want to process custom blocks, but want to use vue-component-compiler.

I don't think customBlocks should be a required argument for assemble

According to #30, the builder that uses vue-component-compiler is responsible for running the script through whatever transpiler is appropriate (e.g. tsc). Is there a way to know which lang was specified for the <script> tag? For <style>, there is a property preprocessLang on the descriptor, but not for the script.

See https://www.npmjs.com/package/vue-component-compiler (HTTP 500)

Output from npm ci

npm ERR! code E404
npm ERR! 404 Not Found - GET https://registry.npmjs.org/@vue/component-compiler/-/component-compiler-4.1.0.tgz
npm ERR! 404 
npm ERR! 404  '@vue/[email protected]' is not in the npm registry.
npm ERR! 404 You should bug the author to publish it (or use the name yourself!)
npm ERR! 404 
npm ERR! 404 Note that you can also install from a
npm ERR! 404 tarball, folder, http url, or git url.

Any help is much appreciated

I'm trying to figure out what base64 injection does here.But, it seems to redirect this links:

https://developer.chrome.com/docs/devtools/

(vuejs/vue-loader@1123b12)

Hi there.

I'm currently using vue-component-compiler on a custom bundler I wrote. We have an internal Vue component library and we need to bundle each component separately instead of bundling everything into a single file.

I got everything else working but I'm having trouble with the SSR optimizations. As far as I understand I can only compile for SSR or CLIENT but not both at the same time.

Would it be possible to get a compiled component decide what to do on runtime? Right now SSR related pieces in the code just prints if(true). I feel like if I could get it to print if(process.env.VUE_ENV === 'server') instead, it might just work.

I'm also open to other suggestions for 1:1 mapping of .vue files to compiled .js versions.

Thank you for great work!

Howdy,

How does hot reloading work with the latest code? ([email protected])

The last time I worked with this codebase was in December, and hot reloading was straightforward; simply pass in isHot: true:

But that seems to have been removed. If you go to https://github.com/vuejs/vue-component-compiler/blob/master/src/assemble.js and search for "hot", there are no results.

What's the proper way to build vue components with hot reloading using the new API?

(If anyone is familiar with this, could you hop on our Slack at https://slack.parceljs.org/ and message me? I'm @shawwn on there.)

Thanks!

The https://unpkg.com/@vue/[email protected]/dist/assembler.js file is not reflecting the changes introduced in 3.4.4 release, specifically at line 277 and 279 is missing a hasStyle check.

With all the goodness going into Vue right now, I assume the rewrite of vue-component-compiler isn't at the top of the list. Having said that, is there a rough idea for when the rewrite is intended to be complete?

I’m running with rollup-plugin-vue and vue-component-compiler provides a plugin, postcss-clean that causes this message to be output:

clean: postcss.plugin was deprecated. Migration guide:
https://evilmartians.com/chronicles/postcss-8-plugin-migration

This appears to work fine for now, but the API used on postcss-clean.ts:6 is deprecated.

When building a project using rollup-plugin-vue, Yarn 2 will throw an error about postcss not being provided, as it is a peerDependency.

Since this is not a PostCSS plugin, shouldn't it be listed in optionalDependencies as an optional feature alongside Sass, Pug, and others?

I think this is tricky since it involves how the bundler can locate the packages, and in some cases, the runtime may need to be directly inlined (related to #33).
–– Evan

Hello,

Sorry to be asking this, as I appreciate that this may be a stupid question, but I am just unsure.

So I have followed the instructions and successfully compiled and output a .vue component with the output of the assembly function. I am just confused as to what I can do with it after that?

My company requires that we vet all parts of a compilation process (due to security) so we are trying to do it without using other peoples packages.

So I was wondering exactly what am I missing to get this working? Do I need to do something else, like transpile it? as I can see the current exported component once it's been ran through this library is not usable on the browser.

So in short, what do I need to do to the output of the component to get it so I can load it into Vue as a component?

I have the following:

const VueComponentCompiler = require('@vue/component-compiler');
const fs = require('fs');
const path = require('path');

const VueCompiler = VueComponentCompiler.createDefaultCompiler();
const vComponent = VueCompiler.compileToDescriptor('component.vue', fs.readFileSync(path.resolve('component.vue'), 'utf8'));
const assembledComponent = VueComponentCompiler.assemble(vComponent, 'component.vue', vComponent);
fs.writeFileSync('component.vue.js', assembledComponent.code);

Thank you any hints or nudges in the right direction would be extremely appreciated!

Thanks,
Danny

Hi,

vueify transform is really cool. The sublime vue.tmLanguage is also nice.

But perhaprs it is good idea to allow a src attribute to extract some files, sometimes ?

split app.vue...

<template lang="jade">
h1(class="red") {{msg}}
</template>

...to app.vue

<template lang="jade" src="./app.jade">

and app.jade

h1(class="red") {{msg}}

What do you think ?

Prior design thread: #28

Thanks to the great work by @znck we now have a good start to iterate on. I did a quick review of the current codebase and here's a list of things I think we should work on next:

Feature Sync with Latest vue-loader

• functional template support (vuejs/vue-loader@c8a016a, vuejs/vue-loader@585b70c, vuejs/vue-loader@c7b5376)

• optional cache busting when generating source maps for blocks (vuejs/vue-loader@1123b12)

• update gen-id implementation: https://github.com/vuejs/vue-loader/blob/master/lib/loader.js#L89

• template compiler transformToRequire support wildcard (vuejs/vue-loader@c589454)

  • bug fix for srcset (vuejs/vue-loader@ddcea20)

• named exports support (vuejs/vue-loader@2e2aa2b)

• esModule default export support in custom blocks (vuejs/vue-loader@7459a87)

• Scoped CSS transform bug fixes

  • vuejs/vue-loader@c303312
  • vuejs/vue-loader@47c3317
  • vuejs/vue-loader@bcd54d2
  • vuejs/vue-loader@6d3c5b2

• use prettier instead of js_beautify when formatting generated render function in template-compiler

To avoid having to maintain both side in parallel, I'll temporarily limit new features in vue-loader until we refactor it to use this package internally.

Questions still open to Discussion

• Current implementation seems to be assuming a module bundler environment, but technically this package should not be limited to that. (discussion in #33)

• Should hot-reload be handled in here? Currently the hot-reload logic is quite specific to webpack, which should be the responsibility of vue-loader.

• How to distribute the runtime (normalizeComponent and style injection code)? I think this is tricky since it involves how the bundler can locate the packages, and in some cases the runtime may need to be directly inlined (related to #33).

We might need to rethink how assemble works altogether. Rough idea: the base assemble function should assume much less and try to allow the user to decide how to handle styles, hot-reload and the normalization.

/cc @znck @eddyerburgh

https://github.com/yyx990803/vue/issues/732

(vuejs/vue-loader@c589454)

When you import an SFC on Nuxt, it throws the following error even if the Component is SSR ready:
Reason: ReferenceError: document is not defined

This error is fixed by moving this

inside the addStyle function

I cannot see any drawback of doing that, but you know better than me so, could that be done?

• vuejs/vue-loader@c303312
• vuejs/vue-loader@47c3317
• vuejs/vue-loader@bcd54d2
• vuejs/vue-loader@6d3c5b2

We should validate input for assemble so that users can see what they need to pass. For example, if you don't pass styles you get Cannot read property 'some' of undefined.

Instead, we should validate the arguments and throw clear error messages, maybe using superstruct.

Hi, curious whether this project will support lang="ts" ?

Thanks

This line

        if (${e(compiler.template.isProduction)} && css.map) {
          // https://developer.chrome.com/devtools/docs/javascript-debugging
          // this makes source maps inside style tags work properly in Chrome
          code += '\\n/*# sourceURL=' + css.map.sources[0] + ' */'
          // http://stackoverflow.com/a/26603875
          code +=
            '\\n/*# sourceMappingURL=data:application/json;base64,' +
            btoa(unescape(encodeURIComponent(JSON.stringify(css.map)))) +
            ' */'
        }

https://github.com/vuejs/vue-component-compiler/blob/master/src/assembler.ts#L116

breaks SSR because btoa is not available in the global namespace of node.

If you add a check here, SSR will work.

Since the lastest release (4.2.2) I'm getting errors due to an apparent issue with the clean_css usage:

[!] (plugin VuePlugin) TypeError: clean_css_1.default is not a constructor
src/components/layout.vue
TypeError: clean_css_1.default is not a constructor
    at initializer (/home/freek/projects/styleguide/node_modules/@vue/component-compiler/dist/postcss-clean.js:6:19)
    at Object.creator (/home/freek/projects/styleguide/node_modules/@vue/component-compiler/node_modules/postcss/lib/postcss.es6:111:27)
    at SFCCompiler.doCompileStyle (/home/freek/projects/styleguide/node_modules/@vue/component-compiler/dist/compiler.js:133:42)
    at SFCCompiler.<anonymous> (/home/freek/projects/styleguide/node_modules/@vue/component-compiler/dist/compiler.js:116:47)
    at Generator.next (<anonymous>)
    at /home/freek/projects/styleguide/node_modules/@vue/component-compiler/dist/compiler.js:7:71
    at new Promise (<anonymous>)
    at __awaiter (/home/freek/projects/styleguide/node_modules/@vue/component-compiler/dist/compiler.js:3:12)
    at SFCCompiler.compileStyleAsync (/home/freek/projects/styleguide/node_modules/@vue/component-compiler/dist/compiler.js:115:16)
    at Object.<anonymous> (/home/freek/projects/styleguide/node_modules/rollup-plugin-vue/dist/rollup-plugin-vue.js:271:57)
    at Generator.next (<anonymous>)
    at /home/freek/projects/styleguide/node_modules/rollup-plugin-vue/dist/rollup-plugin-vue.js:33:71
    at new Promise (<anonymous>)
    at __awaiter (/home/freek/projects/styleguide/node_modules/rollup-plugin-vue/dist/rollup-plugin-vue.js:29:12)
    at Promise.all.descriptor.styles.map (/home/freek/projects/styleguide/node_modules/rollup-plugin-vue/dist/rollup-plugin-vue.js:267:87)
    at Array.map (<anonymous>)

If I use the yarn "resolutions"-field to downgrade to 4.2.1, the issue disappears. Alternatively, removing the "default"-suffix from "clean_css_1" in node_modules/@vue/component-compiler/dist/postcss-clean.js also fixes the issue on 4.2.2

So far, we have seen the logic of compiling an SFC duplicated in multiple projects:

• vue-loader
• vueify
• rollup-plugin-vue
• jest-vue

...and others. The goal here is to extract shared logic regarding SFC compilation into a dedicated package to avoid redundancy and ensure all of these tools are on the same page regarding SFC features and behavior.

Some initial thoughts. APIs should include:

• SFC -> descriptor parsing
• ? how to handle pre-processors vs. webpack loader chaining
• Template -> render fn compilation
• CSS handling (scoped CSS, postcss plugins, CSS modules)

Not entirely clear how much we should and could extract from vue-loader, as a lot of it is tightly coupled to webpack, but let's discuss.

/cc @znck @eddyerburgh @phanan @vuejs/collaborators

The hot reload API offered by webpack, parcel et.el is similar, but there are minute differences which make it impossible to provide implementations for all bundlers out there. Hence, we should make hot API injectable.

What is required in hot reload?

• If <template> or <script> changes, reload/rerender the component.
• If <style module> changes, delete cached component constructor.
• If the component module is disposed of, do not inject <style>.

Proposed API:

{
  hot: {
    // 1. Wrap code with a conditional statement, checking if hot API is available or not.
    isHot: (expression: string) => string,
    // 2. Generate code calling `hot.accept` with passed handler function.
    accept: (fn: string) => string,
    // 3. Generate code calling `hot.dispose` with passed handler function.
    dispose: (fn: string) => string
  }
}

Related Issue: #51

Hello!

Would you consider supporting compiling .vue SFCs to plain ES6 modules, instead of CommonJS?
That would allow one to use such components through <script type="module">.

Thanks!

(vuejs/vue-loader@ddcea20)

This line in index.js require relative path,

output += 'require("insert-css")(' + style + ');\n'

That cause a problem when we use vueify to make custom components. I always get the error:

gulp-notify: [Laravel Elixir] Browserify Failed!: Cannot find module 'insert-css' from '/Users/pathToMyLaravelProject/resources/assets/js/components'

'/resources/assets/js/components' is the folder where are my custom component.

(vuejs/vue-loader@c8a016a, vuejs/vue-loader@585b70c, vuejs/vue-loader@c7b5376)

I need something update in dependence @vue/component-compiler-utils with version 2.0.0 above.

Hello,
I am using rollup-plugin-vue, but it breaks uglify as of now.
The reason is the es6 syntax of the injected (like *const* __vue_inject_styles__) by this project.

Any thoughts on this??

I'm using rollup-plugin-vue and noticed that if I use postcss-import (or any other postcss plugins to use as a replacement for less/sass) that the module'd class names are not added to the $style object for classes that are contained within imported stylesheets.

I believe it is because postcss-modules is prepended and run before my other supplied plugins here. I can confirm that by inverting and concat'ing the postcss modules fixes the issue for me, however I'm curious if there is a deeper reason for prepending it.

You can find my original issue here for reproduction.

I'm happy to put together a PR if no one sees any reason not to do this.

Would allow you to dynamically imports all your modules.

<template>
  <div class="your html code"></div>  
</template>

<!-- Option 1 -->
<script>
(async () => {
  const { exportName } = await import('importName');

  export default {
    // component details
  };
})();
</script>

<!-- Option 2 -->
<script>
export default (async () => {
  const { exportName } = await import('importName');

  return {
    // component details
  };
})();
</script>

Hi :)

I was just wondering about the status of this project, and when the next release is planned for. I noticed that there haven't been any changes for almost two months.

Are there any plans to resume work on this project? Are there any plans to push the current changes to the npm package?

parcel-bundler/parcel#1052

.vue file compilation source is distributed and duplicated across various projects/repositories. There are inconsistencies (e.g. missing features etc.) among different variants. We are planning to build a bundler agnostic core.

A set of high level goals:

• It should support all existing features (e.g. template languages, scoped styles, css modules, custom blocks etc.)
• It should be usable in browser and node environment.

Any inputs @vuejs/collaborators @evan @eddyerburgh

Cool transpiled language:

http://breuleux.github.io/earl-grey/

Minification crashes once you start using the new binding style (@click, :src, etc.):

        throw 'Parse Error: ' + html;
                              ^
Parse Error: <div class="overlay" @click="close"></div>

This would probably need to configured with the customAttrAssign option, according to their Options Quick Reference

Allow prepend a common style definition in the component which will compile, as you can do using a style-loader in webpack.
For example, it's useful for scss be able to define a set of variables or imports and avoid writing in each component the same lines, as is supported with webpack on vue-loader https://vue-loader.vuejs.org/guide/pre-processors.html#sharing-global-variables

As defined in the types file:

interface TemplateOptions {
  compiler: VueTemplateCompiler
  compilerOptions: VueTemplateCompilerOptions
  preprocessOptions?: any
  transformAssetUrls?: AssetURLOptions | boolean
  transpileOptions?: any
  isProduction?: boolean
  optimizeSSR?: boolean
}

compiler and compilerOptions is required, so if I want to set isProduction to true, I have to set the compiler and compilerOptions together, which I don't want to change at all.

Is there a way to set isProduction without setting compiler and compilerOptions?

(Without setting process.env.NODE_ENV of course.)

At the moment, assemble requires an import/require string for the script.

Not all compilers require this feature, and it makes the process more complicated. For example, vueify and vue-jest can work with the script being inlined.

I propose we add an assembleInline function that returns an es6/cjs module that doesn't include import/require statements.

assembleInline would need to be passed the transformed code, and source maps.

如题，import外部文件时抛出异常

Error: './style/mixin.less' wasn't found. Tried - .

https://github.com/vuejs/vue-loader/blob/master/lib/loader.js#L89

As the title says, even if the style block inside an SFC doesn't have a "scoped" attribute, the resulting DOM will be full of "data-v" attributes. Version 3.3.2 didn't do that yet.

I'm using rollup with the following config:

import resolve from 'rollup-plugin-node-resolve';
import replace from 'rollup-plugin-replace';
import css from 'rollup-plugin-css-only'
import vue from 'rollup-plugin-vue';
import { uglify } from 'rollup-plugin-uglify';
import { minify } from 'uglify-es';

const production = !process.env.ROLLUP_WATCH;

export default {
	input: 'main.js',
	output: {
		file: 'dist/bundle.js',
		format: 'iife',
		sourcemap: true
	},
	plugins: [
		resolve(),
		replace({
			'process.env.NODE_ENV': JSON.stringify(production ? 'production': 'development'),
			'process.env.VUE_ENV': JSON.stringify('browser')
		}),
		css(),
		vue({
			css: false
		}),
		production && uglify({}, minify),
	]
};

I'm building a site that uses Bootstrap 4, and I compile Bootstrap's sass into my application. That works fine. However, if I'm writing a component that needs to import, say, the bootstrap varaibles.scss file, It doesn't work because the vue-component-compiler doesn't know about the import path.

What would be perfect would be a way to pass options to any of the compilers; this would give complete flexibility.