Issue 1:
Do you want to request a feature or report a bug?

Feature Reqeust

If this is a feature request, what is motivation or use case for changing the behavior?

The Problem

In vue-loader, we process Vue single file components that can contain multiple language blocks:

<template>/* ... */</template>
<script>/* ... */</script>
<style>/* ... */</style>

Each of these blocks need to be delegated to other webpack loaders for potential pre-processing. The way it currently works is by overloading the same source module with different inline loader chains:

// (output from vue-loader)
import template from '!!vue-template-compiler!selector?part=template!self.vue'
import script from '!!babel-loader?babelOptions!selector?part=script!self.vue'
import style from '!!style-loader!css-loader!selector?part=style!self.vue'

This does work and we've been using it for quite a long time. However, this leads to a number of problems:

Because all loader options must be inlined, it's impossible to use non-serializable option values.

Because the requests all end in *.vue, we cannot rely on the configured rules in the main webpack config. The user has to duplicate the same config in both module.rules and vue-loader's own loaders option, or we have to somehow infer it correctly.

This can be circumvented if the pre-processor supports a fs-based config file, e.g. .babelrc or .postcssrc, but in some cases the user for some reason cannot use a config file, or the loader in question simply does not support config files.

If the user chains another loader before vue-loader, we have to respect that too. This causes the chained loader to be invoked many times (1 extra call for every language block in a vue file).

(cosmetic) these inline requests result in extremely long module names and makes error and stats output difficult to read.

Proposed API

@TheLarkInn had an experimental idea of a virtual-dependency-loader which is almost what we want. Except it doesn't seem to work as intended. I tested it with a virtual dependency with a filename ending in .js, and a configured babel-loader does not apply to the loaded virtual module.

I propose a new loader context API loadVirtualModule that is similar to loadModule:

// in a loader
module.exports = function (source) {
const cb = this.async()

const descriptor = vueCompiler.parseComponent(source)

this.loadVirtualModule({
code: descriptor.script.content,
map: descriptor.script.map,
filename: './does-not-exist.js'
}, (err, code, map) => {
// the script part of the source, processed with all matching loaders
// for does-not-exist.js
})

// even better if it returns Promise
Promise.all([
this.loadVirtualModule({ ... }), // script
this.loadVirtualModule({ ... }), // template
this.loadVirtualModule({ ... }), // style
]).then(parts => {
const { code, map } = vueCompiler.assemble(parts)
cb(null, code, map)
})
}

This would greatly simplify the implementation of vue-loader and solve the problems we are facing above.

Issue 2:
Is there a way to mangle/uglify Webpack globals? Option for it? Even hacky way?

Few examples: __webpack_exports__, moduleName__WEBPACK_IMPORTED_MODULE_0__

My bundle is extremely size-sensitive and these are 10-15% of my bundle.

https://stackoverflow.com/questions/61216115/uglify-webpack-globals

Really sorry about question here but I've adventured like a week in SO, gitter, etc - no answers.