We Keep Coding

Vue 3 & Vite built application shows blank page

I have a problem trying to make a build of a new Vue3.js + Vite.js application. Once my application is finished i made the npm run build action in order to generate the final deployment files.
Problem is that when I try to see the generated page, it only shows a white page.
Opening the inspection tool I can see how the main generated javascript files are like not being found by the static index.html:
Failed to load resource: net::ERR_FAILED index.7b66f7af.js:1

Ok. I found the solution searching a bit, and I see how this problem also occurred actually in Vue 2.
The only thing that you have to do for solvif is add base: './' in your vite.config.js, like this:
import {
defineConfig
} from 'vite'
import vue from '#vitejs/plugin-vue'
import vuetify from '#vuetify/vite-plugin'
const path = require('path')
export default defineConfig({
plugins: [
vue(),
vuetify({
autoImport: true,
}),
],
define: {
'process.env': {}
},
resolve: {
alias: {
'#': path.resolve(__dirname, 'src'),
},
},
base: './',
})
Hope it helps you all!

I had this problem also, and found a solution:
It looks like the awnser given by #javi But it's different. I found out that the situation changes when you deploy your application.
In vite config there is a setting called 'base' filled in like: base: mode === 'production' ? '/nameExample/' : '/', this will put the output of your project on the endpoint : 'nameExample'. If you go in production this fails and shows a blank page, and you need to changes this nameExample to '/' to show the projectbuild online. But than it shows a blank page in development because it mismatches the name of the project. Hope this will help you.

SCRIPT5005: String expected - Rxjs crashes on IE 11 symbol polyfill

At work we have (sigh!) to support IE 11 for the current project I'm working on.
The project uses RxJS 6.
To support most of the features we've included, we used Webpack with Babel and core-js (as suggested by Babel itself) as polyfiller.
If we try to import RxJS, our application loading get stuck on a specific line:
Observable.prototype[_symbol_observable__WEBPACK_IMPORTED_MODULE_2__["observable"]] = function () {
return this;
};
with the error SCRIPT5005: String Expected.
We are using the es5 transpiled version of RxJS. So the code original typescript code should be this one.
I know symbols are not supported in IE 11, as per Kangax's Ecmascript compatibility table and that core-js includes a polyfill for Symbols, and we are importing all the polyfills.
In fact, if I try to run this with the polyfill after the error through the console, it works perfectly.
var obj = {};
Object.defineProperty(obj, Symbol.for("test"), {
value: 5
});
What's weird is that if I try to set a breakpoint on the line that give us the error, I can access singularly to these components without problems.
Observable.prototype
_symbol_observable__WEBPACK_IMPORTED_MODULE_2__
_symbol_observable__WEBPACK_IMPORTED_MODULE_2__["observable"]
The second and the third lines returns me an object.
If I do manually Observable.prototype[_symbol_observable__WEBPACK_IMPORTED_MODULE_2__["observable"]] it still returns me the error.
Accessing to Object.prototype through an Object is not allowed (as using an object as index makes the container object automatically call .toString() on the key). Therefore IE returns me that error. Or, at least, I think that might be the reason.
What's more weird is that Symbol.for("test") returns an object that is the same as _symbol_observable__WEBPACK_IMPORTED_MODULE_2__["observable"] (with description: test instead of observable). And if I do obj[Symbol.for("test")] it works perfectly.
Also, it seems like I'm unable to create variables or such while I'm stopped on a breakpoint in IE 11 console, so I cannot even export that symbol to test that later (it allows me to do var x = {}; or var x = 5, but if I call 'x', it throws me 'x' is undefined).
Any clues about this problem and how we might solve this?
Might this be a problem of the polyfill?
I'm attaching here below my webpack config and my .babelrc
module.exports = {
module: {
rules: [
{
test: /\.jsx?$/,
use: {
loader: 'babel-loader',
options: {
presets: ['#babel/preset-env', '#babel/preset-react', '#babel/preset-flow'],
},
},
exclude: /node_modules\/(core-js|(react.+)|(rxjs.+))/,
},
...
]
}
}
{
"presets": [
"#babel/preset-react",
"#babel/preset-flow",
["#babel/preset-env", {
"targets": {
"browsers": [
"last 2 versions",
"safari >= 7",
"Explorer 11"
]
},
"useBuiltIns": true
}]
],
"plugins": [
"#babel/plugin-proposal-object-rest-spread",
"#babel/plugin-transform-runtime"
],
"env": {
"test": {
"presets": ["#babel/preset-env", "#babel/preset-react", "#babel/preset-flow"]
}
}
}
Thank you.

TL;DR
Since we have a monorepo with multiple projects (a "sample app" that loads another project on its inside), I was including the core-js polyfill both on the sample app and in that project.
They were somehow conflicting, I'm still not sure why and how. This wasn't concerning rxjs but affecting it.
Also, I wrote a wrong regex on the webpack.config.js on babel-loader, but I'm not sure this was really affecting all.
It was: /node_modules\/(core-js|(react.+)|(rxjs.+))/
It should have been: /node_modules\/(core-js|rxjs|react[^\s+]*)/
Since I had to target the packages, not the files as I was thinking. I added a more complex regex on react to match also react-dom or other react-things (if any).
I was able to create a sample application that could work without problems.
I discovered RxJS has somehow its own polyfill for symbols.
In fact, running that sample with React, webpack, babel, rxjs but not core-js, wasn't giving any problem. (Note: the sample has core-js installed).
Setting a breaking point on
Observable.prototype[_symbol_observable__WEBPACK_IMPORTED_MODULE_2__["observable"]], reveals this:
While using core-js, it reveals this:
Although this difference, both with and without the sample, it works perfectly on that sample. So I thought how it was possible and thought that I read somewhere that the polyfill should have been loaded only once in the most global object.
Since we are developing a project in a mono-repo that has React-based Website and another complex React component that gets imported on runtime, and that website seemed to need also polyfills, I added core-js import on both the projects.
By removing the one on the website, the error changed (it got stuck on another point not concerning this one).
Moreover, as said in the TL;DR, I think there was a problem with the regex applied on babel-loader.

CSS is breaking on first load, gets corrected on hot reload

CSS on my site is breaking on first build load, but gets automatically corrected when i press command + s on code. Hotreload does the magic here.
On development environment, this issue could be tackle temporarily by making changes and command + s and undoing the same and command + s again. This will trigger a hotreload and ultimately rebundle all assets(including css) and it correctly loads the css on site.
But on staging or production we production build the program by,
NODE_ENV=production IS_BUILDING_NEXTJS=1 next build src
So can't hack there.
I have tried removing all the aliases from webpackConfig but it didn't work.
Below is my next.config.js
const withCSS = require("#zeit/next-css");
module.exports = withCSS({
cssLoaderOptions: {
url: false
},
// NextJS builds to `/src/.next` by default. Change that to `/build/app`
distDir: "../build/app",
webpack: (webpackConfig) => {
webpackConfig.module.rules.push({
test: /\.(gql|graphql)$/,
loader: "graphql-tag/loader",
exclude: ["/node_modules/", "/.next/"],
enforce: "pre"
});
webpackConfig.resolve.alias.handlebars = 'handlebars/dist/handlebars.min.js';
webpackConfig.module.rules.push({
test: /\.mjs$/,
type: "javascript/auto"
});
webpackConfig.resolve.alias["styled-components"] = "styled-components/dist/styled-components.browser.esm.js";
return webpackConfig;
}
});
Expecting the css should load correctly on the first load itself on every environment.
Currently, on development, it is loading correctly on hotreload.
Hotreload doesn't feel right on staging/production.

Below fix worked, which will eliminate the re-render issue and CSS incorrectly applied on component. Got reference from material-ui CSS not working on SSR issue
We would require to set dangerouslyUseGlobalCSS to true
generateClassName: createGenerateClassName({ dangerouslyUseGlobalCSS: true })
to the function createPageContext() in src/getPageContext.js file

webpack 2 expose webworker as global

I'm trying to write tests for a react/redux app, and we have a bunch of webworkers which are currently imported via require('worker-loader?inline!downloadTrackWorker')
I've been going in circles trying to figure out how to separate out this code so I can run tests in node.js without having trouble with loading the webworker.
One solution I came up with was to expose the webworker globally in my webpack, which would mean I could define a stub or mock in my tests.
In my webpack config, I've added
module: {
loaders: [...],
rules: [{
test: require.resolve(APP_DIR + '/helpers/downloadTrackWorkerLoader'),
loader: 'expose-loader',
options: 'DownloadTrackWorker'
}]
}
my trackWorkerLoader is simply
const DownloadTrackWorker = require('worker-loader?inline!./downloadTrackWorker.js');
module.export = DownloadTrackWorker;
I've also tried the above without inline, but no luck.
I'm experiencing two problems.
when I look for DownloadTrackWorker in my console, it is undefined
with my updated webpack.config, I get an error that webpack can't parse may need appropriate loader at
ReactDOM.render(
<Provider store={store}>
<Player />
</Provider>,
document.getElementById('root')
);
Any suggestions on what I'm doing wrong? It appears to me the issues I'm seeing are related.

when I look for DownloadTrackWorker in my console, it is undefined
As the expose-loader notes in Readme - Usage, you need to import it in order to be included in the bundle and therefore exposed. The rules are not including anything but are applied to the imports in your app which satisfy the test. Besides that you're also not applying the loader to the correct file. You want to apply the expose-loader to trackWorkerLoader.js, so the correct rule would be:
{
test: require.resolve(APP_DIR + '/helpers/trackWorkerLoader'),
loader: 'expose-loader',
options: 'DownloadTrackWorker'
}
Now you need to import it somewhere in your app with:
require('./path/to/helpers/trackWorkerLoader');
This will correctly expose DownloadTrackWorker as a global variable, but you have a typo in trackWorkerLoader.js instead of module.exports you have module.export. Currently you're not actually exporting anything. It should be:
module.exports = DownloadTrackWorker;
Instead of inlining the worker-loader in the require (not talking about its option) you can also define it as a rule:
{
test: require.resolve(APP_DIR + '/helpers/downloadTrackWorker'),
loader: 'worker-loader',
options: {
inline: true
}
}
And now you can simply require it without needing to specify the loaders in trackWorkerLoader.js:
const DownloadTrackWorker = require('./downloadTrackWorker');
module.exports = DownloadTrackWorker;
with my updated webpack.config, I get an error that webpack can't parse may need appropriate loader
You're defining both module.loaders and module.rules at the same time. Although module.loaders still exists for compatibility reasons, it will be ignored completely if module.rules is present. Hence the loaders you configured before, are not being applied. Simply move all rules to module.rules.

Webpack Hashing *after* uglification

We're using the style-loader in webpack, which, when compiled seems to place information about the current directory in the source code that injects style tags when modules are loaded/unloaded. It looks roughly like this:
if(false) {
// When the styles change, update the <style> tags
if(!content.locals) {
module.hot.accept("!!./../../../../../node_modules/css-loader/index.js!./../../../../../node_modules/sass-loader/index.js?includePaths[]=/var/deploy/referrals/web_head/releases/20151118202441/node_modules/patternity/node_modules/node-neat/node_modules/node-bourbon/node_modules/bourbon/app/assets/stylesheets&includePaths[]=/var/deploy/referrals/web_head/releases/20151118202441/node_modules/patternity/node_modules/node-neat/node_modules/bourbon-neat/app/assets/stylesheets&includePaths[]=/var/deploy/referrals/web_head/releases/20151118202441/node_modules/patternity&includePaths[]=/var/deploy/referrals/web_head/releases/20151118202441/node_modules/infl-fonts!./campaigns.scss", function() {
var newContent = require("!!./../../../../../node_modules/css-loader/index.js!./../../../../../node_modules/sass-loader/index.js?includePaths[]=/var/deploy/referrals/web_head/releases/20151118202441/node_modules/patternity/node_modules/node-neat/node_modules/node-bourbon/node_modules/bourbon/app/assets/stylesheets&includePaths[]=/var/deploy/referrals/web_head/releases/20151118202441/node_modules/patternity/node_modules/node-neat/node_modules/bourbon-neat/app/assets/stylesheets&includePaths[]=/var/deploy/referrals/web_head/releases/20151118202441/node_modules/patternity&includePaths[]=/var/deploy/referrals/web_head/releases/20151118202441/node_modules/infl-fonts!./campaigns.scss");
if(typeof newContent === 'string') newContent = [[module.id, newContent, '']];
update(newContent);
});
}
// When the module is disposed, remove the <style> tags
module.hot.dispose(function() { update(); });
}
The thing to note is the directory listed in the accept string.
Now, this code ultimately gets removed once uglify is run (because of the if (false)) which is great. Where my problem lies however is that this compilation happens on 2 machines and the chunk hashing appears to happen before uglification, because the hash generated on 2 different machines (or even on the same machine but when in a different folder) is different. This obviously won't work if I'm deploying to, say, a production machine and need both of these machines to serve up an asset with the same digest.
Just to clarify, when not minified, the code is different, thus generates a different hash, but minification does in fact make the files identical, however the chunk hashing appears to have happened before minification.
Does anyone know how I can get the chunkhash to be generated after the uglify plugin is run. I'm using a config like so:
...
output: {
filename: '[name]-[chunkhash].js'
...
with the command:
webpack -p
edit
So after looking over this. I'm seeing now that this has to do with us adding includePaths to our style loader, it looks like this:
var includePaths = require('node-neat').includePaths;
module: {
loaders: [
{ test: /\.scss$/, loader: "style!css!sass?includePaths[]=" + includePaths },
]
}
So I think we know why we're getting these absolute URLs, but I think the original question still stands, IMO webpack should be hashing chunks AFTER minification, not before.