Stack: Webpack 4.16.0, Node8, Vuejs2
I am seeing the below error, whilst serving my Vuejs application.
Error: Loading chunk 4 failed.
(missing: https://myapp.com/ui.chunk.bundle.js)
at HTMLScriptElement.s (demo:1)
This error is consistent across builds, the actual file itself is accesible via the URL.
I am using code splitting via import() and the initial app loads fine, but then the flow will break when another chunk is loaded, it can also vary between ui.chunk.bundle.js & vendors~ui.chunk.bundle.js.
When building for production, a new error is shown, but it seems related as also linked to loading modules:
demo:1 TypeError: Cannot read property 'call' of undefined
at o (demo:1)
at Object.349 (ui.chunk.bundle.js:1)
at o (demo:1)
at o.t (demo:1)
I have tried upgrading webpack and babel, but am at a loss as to what this could be down to as it was working perfectly fine before.
When running the application on my local machine and not Google App Engine, everything seems fine.
How the app is loaded:
It is loaded into other website via a script tag, so domainA.com runs the script tag which calls myapp.com/js and the flow begins, i.e the app loads various chunks based on some logic.
When accessing the webpack generated index page bundle at myapp.com everything loads correctly.
Please help!
That is rather deep and surely not easily fixed in two steps, best you create a new project using cli, if convenient with recommended presets, and if it still persist check the npm packages you installed and make sure none of them are discontinued and are up-to-date at least according to your version of vue.
Its might be due to "webpack.config.js" where you can just try with updating output object
module.exports = {
output: {
chunkFilename: '[id].chunk.[chunkhash].js',
}
};
Hope it should work!
This might be a cross site scripting problem.
Make sure that myapp.com sets the correct headers.
On myapp.com, set this header:
Access-Control-Allow-Origin: https://domainA.com
You should also make sure, that your script tag has async set to false:
<script async="false" …
Related
I have been trying to build my gatsby (react) site recently using an external package.
The link to this package is "https://github.com/transitive-bullshit/react-particle-animation".
As I only have the option to change the props from the components detail, I cannot read/write the package file where it all gets together in the end as it is not included in the public folder of 'gatsby-build'.
What I have tried:
Editing the package file locally, which worked only on my machine but when I push it to netlify, which just receives the public folder and the corresponding package.json files and not the 'node-modules folder', I cannot make netlify read the file that I myself changed, as it requests it directly from the github page.
As a solution I found from a comment to this question, we can use the "Patch-Package" to save our fixes to the node module and then use it wherever we want.
This actually worked for me!
To explain how I fixed it: (As most of it is already written in the "Patch Package DOCS), so mentioning the main points:
I first made changes to my local package files that were giving the error.(For me they were in my node_modules folder)
Then I used the Patch Package Documentation to guide my self through the rest.
It worked after I pushed my changes to github such that now, Patch Package always gives me my edited version of the node_module.
When dealing with third-party modules that use window in Gatsby you need to add a null loader to its own webpack configuration to avoid the transpilation during the SSR (Server-Side Rendering). This is because gatsby develop occurs in the browser (where there is a window) while gatsby build occurs in the Node server where obviously there isn't a window or other global objects (because they are not even defined yet).
exports.onCreateWebpackConfig = ({ stage, loaders, actions }) => {
if (stage === "build-html") {
actions.setWebpackConfig({
module: {
rules: [
{
test: /react-particle-animation/,
use: loaders.null(),
},
],
},
})
}
}
Keep in mind that the test value is a regular expression that will match a folder under node_modules so, ensure that the /react-particle-animation/ is the right name.
Using a patch-package may work but keep in mind that you are adding an extra package, another bundled file that could potentially affect the performance of the site. The proposed snippet is a built-in solution that is fired when you build your application.
I can't seem to change any of my JavaScript files without restarting the server - it really kills a lot of the live-reloading fun of working in Phoenix. I don't do a ton of JavaScript, so I'm not sure if I'm doing something wrong.
Phoenix version: 1.2.0
Steps to reproduce:
Create a new project with mix phoenix.new foo
Create web/static/js/foo.js file.
In that file, write alert("Hello, world!");
In app.js, include import "web/static/js/foo" at the bottom.
Start Phoenix with mix phoenix.server and navigate to localhost:4000.
It doesn't matter how many times you refresh the page, you'll see an alert box with "Hello world!" every time, without fail.
Edit the foo.js message to be "Hello worlds!"
I expect that I'll still get an alert message with updated text, but the alert boxes stop appearing - altogether. They only start appearing again when I restart the server.
Is this intended behavior? A bug in Phoenix? Am I writing my JS code in a way that Brunch doesn't expect it? Is this a Babel issue? Should I be organizing my code differently?
Should add that I'm developing in Chrome on Linux - in case this might be a browser issue
Edit: I can't reproduce this exact issue anymore, but I'm still having issues with my non-toy project:
My original issue was in the app I'm actually developing - where I have global.jQuery = require("jquery") and global.bootstrap = require("bootstrap") in app.js. If I comment those two lines, save, and uncomment, I get a Javascript error in the browser: app.js:16Uncaught Error: Cannot find module 'jquery' from 'web/static/js/app.js'
Is this intended behavior? Yes.
A bug in Phoenix? No.
Am I writing my JS code in a way that Brunch doesn't expect it? Right you are.
Is this a Babel issue? Nope.
Should I be organizing my code differently? Probably.
Brunch (or Node.js or any other module bundler) expects relative path in import statement: it fails to resolve web/static/js/foo from web/static/js/app.js and does not mark foo.js as dependency of app.js (entry point). That is why it does not rebuild app.js when foo.js is changed. When Brunch is restarted, it completely rebuilds app.js, with latest foo.js (Brunch includes it because of joinTo.javascripts in config) version from the disk.
Specify relative paths (import "./foo") and prefer import jquery from ... over global.jquery = ...
Disable caching (if enabled) in your client (browser).
Disable caching (if enabled) in your server.
I have been trying to port HTML5 with js code into Meteor. I'm having Javascript dependency problems.
The code can be found at: https://github.com/cwilso/Audio-Input-Effects
I created a new basically empty meteor project (which runs fine) and then added all of the js files from the repo above (which also runs fine on its own).
In order to make sure that the load order was correct, I renamed all the js files using numeric prefixes so that they would definitely be in the same order that they are loaded in the github repo. Looking forward to Meteor coming up with a better solution to this particular issue. I made a local copy of one js file that was otherwise loaded from a url in the repo.
In order to try to initialize the js I also added a file hello.js:
if (Meteor.isClient) {
Meteor.startup(function () {
// code to run on server at startup
initAudio;
});
}
When meteor runs and I look in the console, I get the following errors:
Uncaught TypeError: o3djs.provide is not a function (120_shader.js)
Uncaught ReferenceError: initAudio is not defined (hello.js)
Uncaught ReferenceError: Matrix4x4 is not defined (110_visualizer.js)
Thank you for your help.
I was able to resolve this issue by putting all of the js source files into a single js file in the correct order.
Anybody still wanting information regarding meteor load order, Scotch.io wrote an update to the official docs which clears it up somewhat.
https://github.com/meteor/meteor/commit/a5bdf481dfece9ebc57107d71be478f9b48cbd1e
In my Angular JS app, I'm using a lot of third party packages, mainly maintained via Bower.
When I use Grunt to concatenate all of them into one mega file, I'm getting errors when I load my page, for example that
Uncaught ReferenceError: angular is not defined and
GET http://localhost:8080/theproj/v4/dist/app/bootstrap.css.map 404 (Not Found)
What is the best way to properly concatenate all these files to ensure that everything loads in the right order and doesn't cause problems?
First issue: A lot of times third party libraries must be loaded in a particular order. That looks like like it's the source of your first issue. Something is trying to use angular and it's getting loaded before the angular code. You should refactor your grunt task to use a pre-defined order for third party libraries.
Second issue: You probably are missing the .map file. This is a file used by Chrome dev tools to show you the original source for the css (sass or less). Either provide the map file, or delete the reference to it from bootstrap.css. Or just ignore the error, it's only an error when you have chrome dev tools open, and doesn't actually affect your application.
For the issue of the correct order for your javascript files, i had that problem in a larger project where noone really had a clue which was the correct order.
Luckily we found that the Google Closure Compiler does exactly this: https://github.com/google/closure-compiler
You give it all your js files and it analyzes them all and concatenates them in order
$ java -jar compiler.jar --js_output_file=out.js in1.js in2.js in3.js ...
There is even a grunt plugin for the connection: https://github.com/gmarty/grunt-closure-compiler
'closure-compiler': {
frontend: {
closurePath: '/src/to/closure-compiler',
js: 'static/src/frontend.js',
jsOutputFile: 'static/js/frontend.min.js',
maxBuffer: 500,
options: {
compilation_level: 'ADVANCED_OPTIMIZATIONS',
language_in: 'ECMASCRIPT5_STRICT'
}
}
},
Another way would be to change your javascripts into AMD or CommonJS modules, this way you don't have to worry about the correct order. RequireJS (http://requirejs.org/docs/start.html) is a possibility for AMD for example or Webpack (http://webpack.github.io/) ...or many many others.
I'm getting an error about Application.js not being found once I've copied the application over to a web server.
http://site/app/Application.js?_dc=1404504339794 404 (Not Found)
But obviously, this is wrong since once you run sencha app build everything is minified to app.js.
I looked at the generated app.js and index.html and there is no mention of Application.js anywhere.
I'm running: sencha app build production and copying the content of the production build over.
I am also getting a C1009: Circular reference warning during the build. And here it is:
in /controller/MainContent.js at line 192
var w = Ext.widget('EditPortalUserWindow'); //this creates a widget defined in the MainContent.js VIEW
And within that view at some point in one of the widgets, I use this to define the URL of a form:
url: GlobalVars.contactPostApiUrl //if I comment this out, the warning goes away...
GlobalVars is defined in app.js
Ext.define('GlobalVars', {
singleton: true,
contactPostApiUrl: 'http://site/CustomerPortal.WebAPI/api/contact/post'
});
I want GlobalVars to be available from everywhere, which is why I put it in app.js.
Any ideas ? Thank you!
I have seen something similar already - the production build requiring files it shouldn't. The following should help:
run the development version and see if you get any synchronous loading warning, fix if yes.
run sencha app build --clean
If it does not help run this sequence
sencha ant clean
sencha app refresh
sencha app build
#Francis Ducharme Adding to the above coversation , i m sending u two links which i guess might help u with C1009 .
C1009 Link 1
C1009 Link 2
I "solved" this issue by actually creating the file it is looking for (an empty one) and this seems to work. Although I feel a bit uncomfortable with this fix.