I am building a micro front-end using Vue 3, Typescript, and Vite and for this, I have a wrapper in single-spa, let's call it wrapper.product.com.
And I also have a micro front-end, let's call it A, so it is placed at a.product.com and it is built using code split.
The problem is that A only works with referenced dependencies. Therefore, when A tries to get assets/somefile it tries to fetch from wrapper.product.com/assets/somefile.
I am also using the build.base in the vite.config.ts to mention the right domain, but it didn't work.
I know there is a possible solution using webpack (systemjs-webpack-interop) but is it possible with Vite?
Any ideas to fix this and have all dependencies of A being fetched from the A domain?
Related
I have a very particular question, cause I wish to create a webpage that works without a server, and I'm trying to do it using vite, my whole project is using vue + vite.
if I try to use "vite build" command, the page deploy as blank, and the only way I can see the page is if I use "vite preview".
would it be possible, somehow, to load the content of the html page using vite, without needing the "vite preview"? just double clicking on index.html
Using vue-cli, this is possible by setting the publicPath in the vue.config.js file to an empty string, see: https://cli.vuejs.org/config/#publicpath
I've personally only used it with Vue 2, but from what I read online it should also be possible with Vue 3, if you're okay with switching to vue-cli.
Using Vite, I found this question and answer which shows a way by bundling all the scripts, css and images into a single file:
How to open a static website in localhost but generated with Vite and without running a server?
I did try that and it mostly works, but not currently for svg files which I use a lot of in my application. It might work fine for your use-case.
I did also need to add "type": "module", in my package.json to get rid of an error saying
"Error [ERR_REQUIRE_ESM]: require() of ES Module
/path/to/dist/index.js from /path/to/vite.config.inlined.ts not
supported."
If you open your page simply as an index.html, you will be limited regarding some API calls and alike. Nowadays, you will need a light server to be hosting it via a simple vite preview as you saw. This is mainly because the files are being worked with bundlers like Webpack and Vite.
I'm not sure that there is a way of loading the whole thing with just an index.html because files like .vue are not natively supported, you need a specific loader.
One simple solution would be to use Vue as a CDN, but it will limit your DX experience regarding SFC files, but you will be able to use Vue into a regular index.html file.
PS: your performance will also be worse overall (because of the required network requests).
If you want something really lightweight, you could of course also use petite-vue, maybe more suited towards super simple projects with a tiny need of reactivity.
I still recommend using something like Netlify or Vercel, to host your static site for free + having the whole Vue experience thanks to a server running vite preview for you.
I have a frontend project setup with preact-cli, which leverages i18next with http-backend. This configuration is to facilitate the serving of the translations on demand from the CDN the app is to run in production on. So far I can get this to work by doing:
npx preact build --no-prerender
followed with a deploy to AWS Cloudfront
Now I would like to statically prerender some of the major routes, but regretfully, a naive: preact build --prerenderUrls ./prerender-urls.js does not work. The reason for this is that once it is to do the step of prerender-ing those routes, it is trying to leverage the i18next-http-backend in the absence of an http server running. At this point, preact build just keeps on hanging(as if I am doing a preact build --analyze).
As such, for that step, I need to use the i18next-fs-backend instead. Regretfully, while this will work for bundling in the translations on a CI/CD-server for those prerendered routes, it will not work for the translations that need to be served over the http-backend.
I only see two types of solutions to this problem:
Do the build in two steps. First with --no-prerender with an i18n.config.js that leverages the http-backend and then with --prerender with an i18n.config.js that leverages the fs-backend. The problem here is that the hashes are different between the two builds so I can not simply copy over the prerendered routes with the other build.
Setup an http server during the build that can serve those translations. This is possible in itself, but a rather brittle work-around.
There is the concept of a chained-backend with i18next that would allow me to define a fallback, but in the context of a browser, how does it make sense to have i18next-fs-backend as the primary source?
What would greatly help me at this stage is if someone can point out that
Either there is a third viable option that I failed to consider
Either I misunderstood some way of doing chained-backend
Either a confirmation that I am correct and that a strong case can be made that preact-cli needs to allow us to do the build in two parts.
I am building a very small application that uses everything from CDNs, including Vue.js, so far everything has worked great, but I want to load another CDN now - this one.
I'm used to that via ES6 (and usually Laravel's stuff takes care of that - do I have any way of including the CDN listed on that page and using including it in my code?
Simply including the CDN via script before everything else didn't work.
You can include the script tags in the index.html or any other html which you use to initialize your root vue component.
I'd like to compile ".vue" components (with contains html/js/css) into JS, but in browser side, without browserify/vuify/webpack or others ...
In a better world, i'd like to include my ".vue" component into my html app, like that, withoud need of compile things, server side:
<script type="vuejs/component" src="myComp.vue"></script>
It should be possible ?! no ?
(And I can't imagine that no one got this idea, or have done it already)
In fact, it's possible with http-vue-loader :
https://github.com/FranckFreiburger/http-vue-loader
It doesn't make sense to compile in the browser when it's so much more efficient to just pre-compile your component locally instead of relying on a visitor's client to do it.
In fact, the answer above regarding vue-http-loader says it's only for use in development and links to this article: https://vuejs.org/2015/10/28/why-no-template-url/
With that said, I created a vue-cli template that lets you pre-compile .vue files into a single .js files you can use in the browser. The single JS file contains the template, script, and styles. It uses webpack, but it's super easy to run and watches your files as you edit them.
$ vue init RonnieSan/vue-browser-sfc my-project
Repo at: https://github.com/RonnieSan/vue-browser-sfc
Instructions are in the README.
I'm using sails(http://sailsjs.com) to develop a little platform. Everything goes smoothly following the documentation. But being new to this javascript frameworks world and npm etc etc, i've been having a trouble including other node_modules and use them in the .ejs views...
I understand not all modules are to be included in the views but how can I manage to include some?
Trying to use https://www.npmjs.com/package/vue-slider-component
Thank you in advance and sorry if this error is just plain out stupid.
Your confusion is understandable. The issue is that, until relatively recently, things installed in node_modules were solely for use in the back end code; that is, your Sails.js controller actions, models, etc. After all, the node_modules folder has the word "Node" right in it, and it was created for use with NPM (the Node Package Manager) to help organize Node (i.e. server-side JavaScript) files!
While many front-end plugins were (and still are) published on Bower, newer frameworks like Angular 2 and Vue often publish their plugins to NPM because it reduces the number of moving parts for your app. The problem is, if you try to require('vue-slider-component') in your server-rendered .ejs view, the server (i.e. Sails.js) will try and load and run that code before it renders the view, where what you really want is for that plugin to run in the browser.
The long-term solution is to use something like Browserify or Webpack to compile all of your front-end JavaScript files into a "bundle". So for example if you have a file like assets/js/my-vue-app.js that includes the line:
import vueSlider from 'vue-slider-component/src/vue2-slider.vue'
then Browserify will see that line, load up that vue2-slider.vue file, add it to the top of the my-vue-app.js file, perform some other magic, combine it with your other front-end .js files and output a file like browserified.js which you would then include via <script src="/path/to/browserified.js"> in your HTML.
Since new Sails apps use Grunt to organize and inject those <script> tags into your views for you, it can be kinda confusing as to how you would get something like Browserify or Webpack to work with Sails. For Sails 1.0, there's a seed project for using Webpack instead of Grunt. For Sails v0.12.x, you'll have to Google around to find some examples of using Broswerify or Webpack with Sails.
A short-term solution, and probably not as maintainable in the long run, is to save the contents of the minified vue-js-slider component into your assets folder (e.g. as assets/js/vue-slider-component.js), add it to your HTML with <script src="/js/vue-slider-component.js"> and access it in your code as window['vue-slider-component'].