multiple entry points?
-
Hi, im moving my app from vue cli3 + vuetify where in have two entry points.
I’m using: https://cli.vuejs.org/config/#pages
Is it possible to configure it with quasar cli?
My vue.config.js file looks like that:
module.exports = { pwa: { name: 'app' }, devServer: { port: 5004 }, pages: { app: { entry: 'src/main.js', template: 'public/index.html', filename: 'index.html', excludeChunks: ['silent-refresh'] }, 'silent-refresh': { entry: 'src/silent-refresh.js', template: 'public/silent-refresh.html', filename: 'silent-refresh.html', excludeChunks: ['app'] } } }
Thanks for any tips
-
Due to no answers in some time I will try to add some detailed questions.
Is it even possible to have multiple entry points with quasar cli?
Maybe I can use some package or extension to build two js files in one time to one directory?If not how do you think I should hack this?
Should I biuld my second entry point and copy it to statics folder? -
@lucaste it would be nice to have an opportunity to generate multiple html files. As for now, Quasar works in SPA - SINGLE page application mode. If you want multiple html pages in one www directory I can think of such options:
-
you could make different quasar project for every page. There is an option in configuration, where you can change default “index.html” to anything. Quasar wisely produces unique file names (for css,js etc), so you could copy all of them into a single www directory.
-
there is a router in Vue so if it’s ok then you can use single index.html with # routings - index.html#page1 or index.html#page2. Ugly but works.
-
you could make a SSR project in Quasar with all the pages you need as in previous solution and then make some rewrite rules on your reverse proxy. In example index.html -> ssrhost/index.html#index, mypage.html -> ssrhost/index.html#mypage etc.
-
you can write feature request on Quasar github page and wait until it will be implemented. I’m somewhat sure, that sooner or later this will be easily possible, because multiple pages from one project is a rather common use case.
-
-
Thanks @lucaste for saving me a couple hours! I had the same problem and was wondering if Vue Router Pages would be the solution. It seems like it’s not.
In my example:
- I have my main SPA app, plus a
/login
page with a simple form. - I want my users to be able to land on
/login
. (Multiple entry point here). - Main app and Login have the same header and footer components.
@qyloxe thanks for your suggestions.
- you could make different quasar project for every page. There is an option in configuration, where you can change default “index.html” to anything. Quasar wisely produces unique file names (for css,js etc), so you could copy all of them into a single www directory.
Three concerns I have with this one:
- I am not sure how well that will play in Cordova/Electron. Ultimately I want both of these pages to be in the same mobile app (user lands on Login page first, then goes to the main app).
- The shared components/assets (e.g. footer and header) are going to be downloaded twice – same content, different names as you said.
- I’ll have as many
quasar.conf
files as my entry points. Managing them is going to be tricky given I might want to make a change on all of them (copy and paste them same setting in multiple conf files will be so error-prone).
- there is a router in Vue so if it’s ok then you can use single index.html with # routings - index.html#page1 or index.html#page2. Ugly but works.
I am using history mode to save on the ugliness.
So it’s important for me to have www.mydomain.com/login URL to work.
- you could make a SSR project in Quasar with all the pages you need as in previous solution and then make some rewrite rules on your reverse proxy. In example index.html -> ssrhost/index.html#index, mypage.html -> ssrhost/index.html#mypage etc.
Actually, I tried going down the SSR path but I got bummed out and lost with a lot of “window is not defined” in my Client Side libraries. I wish there was an architectural guidance on that.
The fact of the matter is, I don’t need SSR here, per se. I don’t need the Login page to be rendered in server side necessarily. I just want to have a second entry point.
- you can write feature request on Quasar github page and wait until it will be implemented. I’m somewhat sure, that sooner or later this will be easily possible, because multiple pages from one project is a rather common use case.
I really hope so. Until then, I will appreciate any idea/brainstorming. Thanks, guys!
- I have my main SPA app, plus a
-
PS. The solution I am going to go with, for now, is similar to your #2. I am going to have my Nginx do reverse proxy anything like
mydomain.com/login
tomydomain.com/index.html?from=/login
, then in my router, at the first rendering time, I’ll try to parse thatfrom
query parameter and make an internal programmatic navigation to that page. -
… aaaaaaaand (3 hours later) apparently
quasar server
has a--history
which does this and makes it work like a charm! -
I must admit, it’s quite tricky to set up a second entry point. In my case I needed to load the app with different headers through different index.html depending on the domain.
The only solution I found was to tell webpack directly, in my quasar.conf I have something like :
const env = require('quasar-dotenv').config(); const HtmlWebpackPlugin = require('html-webpack-plugin'); module.exports = function (ctx) { return { ... build: { ... extendWebpack(cfg) { ... cfg.plugins.push( new HtmlWebpackPlugin({ template: `${__dirname}\\src\\index2.template.html`, filename: 'index2.html', chunks: 'all', ctx: ctx, process: { env: env }, productName: "PageTitle", productDescription: "PageDescription" }) ); } } } }
/!\ The second index will be generated referencing the same assets and bundle.js
-
@LaZe hmm, your solution looks quite promising. I must admit, that multiple output html files would be VERY interesting for Quasar. I can think of scenario, where you would generate multiple html files and then compile them with quasar/webpack, put them on the static host and voila, the website of an army of simple and small SPAs is ready!
-
@LaZe @rstoenescu
Your configuration which allows build multiple html files works ok. I created test project and it produced two other html files. Please note, that I added option “hash” which is nice to have and option “minify” which didn’t worked:cfg.plugins.push( new HtmlWebpackPlugin({ template: `${__dirname}\\src\\index2.template.html`, filename: 'index2.html', chunks: 'all', ctx: ctx, process: { env: env }, productName: "PageTitle 2", productDescription: "PageDescription 2", minify: true, hash: true }) ) cfg.plugins.push( new HtmlWebpackPlugin({ template: `${__dirname}\\src\\index2.template.html`, filename: 'index3.html', chunks: 'all', ctx: ctx, process: { env: env }, productName: "PageTitle 3", productDescription: "PageDescription 3", minify: true, hash: true }) )
What is the problem? Both files (index2.html and index3.html) are using the default App.vue skeleton because the whole build process is using those files during build:
.quasar/app.js .quasar/client-entry-js etc.
If you want to use a App2.vue for index2.html and App3 for index3.html with this config this is unsolvable.
BUT - if it could be possible to “slightly”
modify “quasar.conf.js” with some extra options, then we could have quite easily multiple output files with quasar!
As for now, the “quasar.conf.js” works like this:
module.exports = function (ctx) { return { // whole quasar app config which results in single index.html file } }
What if it could be possible to write something like this:
module.exports = function (ctx) { return [ { // configuration for index.html with App.vue }, { // configuration for index2.html with App2.vue }, { // configuration for index3.html with App3.vue }, { // configuration for electron app with AppElectron.vue :-) } ] }
I think this is a interesting concept. With this technology one could create whole app servers, integrated sites, variant pages, use quasar as generator/compiler for any legacy technology or even … wow, let me stop here, getting too excited
-
@eyedean said in multiple entry points?:
PS. The solution I am going to go with, for now, is similar to your #2. I am going to have my Nginx do reverse proxy anything like
mydomain.com/login
tomydomain.com/index.html?from=/login
, then in my router, at the first rendering time, I’ll try to parse thatfrom
query parameter and make an internal programmatic navigation to that page.Why not just use html5 history mode in vue-router? That should be good enough to hot-link directly to the login page.
-
Hello I’ve a problem with productName:
Html Webpack Plugin:<pre> Error: ReferenceError: productName is not defined - index.twig.template.html:97 /src/index.twig.template.html:97:11 - index.twig.template.html:106 98bd.module.exports /src/index.twig.template.html:106:3 - index.js:400 [client2]/[html-webpack-plugin]/index.js:400:16 - task_queues.js:82 processTicksAndRejections internal/process/task_queues.js:82:5 - async Promise.all </pre>