Support configuring Vue apps with `vue.config.js`
BickelLukas opened this issue ยท 8 comments
Description
When installing vue cli plugins, they sometimes need to be configured via vue.config.js (ex @vue/cli-plugin-pwa)
This configuration is not possible right now.
Motivation
The configuration of these plugins should be possible.
Suggested Implementation
add a vue.config.js to the application and allow configuration there. This configuration should get merged in with the standard config.
Thanks for creating this issue. I explain my current position on adding vue.config.js
support here.
At this time, we want to wait for more user feedback about this before deciding on a direction.
For the example of @vue/cli-plugin-pwa
that you mentioned, support for configuring that in workspace.json
can be added. If there's another use case where you've been blocked because workspace.json
isn't as configurable as vue.config.js
please explain that. Also, we'd appreciate your contribution if you want to add the pwa
option. I can provide direction on how to do that if you'd like to work on it.
Is vue.config.js support still on the roadmap?
Also, we'd appreciate your contribution if you want to add the
pwa
option. I can provide direction on how to do that if you'd like to work on it.
Nice work on the migration to NX 13, I'd like to take a crack at adding the pwa
option. Share those directions with me and I'll give it a go.
I'd like to +1 the vue.config.js
functionality. I'm currently trying to run a custom loader that runs prior to the vue-loader
. I cannot seem to find an easy way to achieve this via Webpack configuration, whereas it's a few simple lines in vue.config.js
.
// ./vue.config.js
module.exports = {
chainWebpack: config => {
config.module
.rules
.get('vue')
.use('components')
.loader(require.resolve('./custom-loader'))
.before('vue-loader')
.end()
}
}
If there's an alternative way to achieve this in the current functionality, I'd love to know of it. Otherwise, while I understand that having both vue.config.js
and configure-webpack.js
together isn't ideal, it seems worse to throw away a significant portion of Vue's core configuration just because it's a slightly weird process. It's built into Vue and it only makes sense to have it included if we want to achieve Vue parity with other frameworks on Nx.
Yeah, I've spent a ton of hours trying to get vuetify3
working with nx-plus/vue (#233), but have not been successful, yet ๐.
Where should plugin specific code go?
For instance, my vue.config.js has the following items in it that I don't know where to put:
transpileDependencies: ['vuetify'],
pwa: {
name: 'SkyCourt',
themeColor: '#4c97d2',
appleMobileWebAppCapable: 'yes'
},
productionSourceMap: false,
pluginOptions: {
i18n: {
locale: 'en',
fallbackLocale: 'en',
localeDir: 'locales',
enableInSFC: false
}
},
It also had devServer which I have successfully moved to project.json.
It also has a publicPath defined like this.
publicPath: process.env.NODE_ENV === 'production' ? '/sc/' : '/',
I see that I can have publicPath: "/" defined in the serve.options and then in the serve.configurations.production, I can put publicPath: "/sc/".
I also had two sections for webpack, which I assume I have to figure out how to migrate these into configure-webpack.js:
configureWebpack: {
devtool: 'source-map',
resolve: {
alias: {
'@components': resolve('src/components'),
'@common': resolve('src/common'),
'@helpers': resolve('src/helpers'),
'@pages': resolve('src/pages'),
'@plugins': resolve('src/plugins'),
'@store': resolve('src/store'),
'@locales': resolve('src/locales'),
'@enums': resolve('src/api/Enums'),
'@api': resolve('src/api/Interfaces'),
'@services': resolve('src/api/Services'),
'@use': resolve('src/use'),
'@assets': resolve('src/assets'),
'@vue/composition-api$': '@vue/composition-api/dist/vue-composition-api.mjs'
}
},
plugins: [
new WebpackAssetsManifest({
output: 'asset-manifest.json'
})
// new webpack.IgnorePlugin({
// resourceRegExp: /^\.unit\.ts$/,
// contextRegExp: /.*/
// })
//, new BundleAnalyzerPlugin()
]
},
chainWebpack: (config) => {
// This is here because by default webpack doesn't properly handle const enums
// in .d.ts or .ts namespaces. This modification of config.module.rule('ts')
// is needed to get ts-loader to properly handle them.
// https://github.com/vuejs/vue-cli/issues/2132#issuecomment-431355597
const rule = config.module.rule('ts');
rule.uses.delete('thread-loader');
rule
// The .test and .exclude are supposed to set webpack to only
// compile .ts and NOT .test.ts. This config does what I wanted
// it to output, but that output isn't doing what I expected.
// I don't understand how files are being picked for ts compilation
.test(/\.ts$/)
.exclude.add(/\.test\.ts$/)
.end()
.use('ts-loader')
.loader('ts-loader')
.tap((options) => {
options.transpileOnly = false;
options.happyPackMode = false;
return options;
});
},
Any suggestions would be much apprecited.
This is all Vue 2 as I wait for Vuetify to become fully available for Vue 3.
Oops, I just noticed that there is explicit support for the transpileDependencies already.
I thought I had figured out how to get the rest of the vue.config.js configuration to work since Vue allows you to put vue.config.js elements in the package.json file under the "vue" node.
This would have been a great spot to put anything that isn't explicitly supporte by the this nx plugin. Unfortunately the nx plugin itself blocks that and throws this error when it finds a "vue" node in package.json:
throw new Error(`You must specify vue-cli config options in '${workspaceFileName}'.`);
^
Error: You must specify vue-cli config options in 'workspace.json'.
at Object.<anonymous> (C:\Users\Greg\source\repos\SquashSpider\SquashSpider\SkyCourt.UI\skycourt\node_modules\@nx-plus\vue\src\utils.js:43:19)
at Generator.next (<anonymous>)
at fulfilled (C:\Users\Greg\source\repos\SquashSpider\SquashSpider\SkyCourt.UI\skycourt\node_modules\tslib\tslib.js:115:62)
So I would say that at least one more thing is required to be supported in the workspace.json file. We need support for pluginOptions.