So when you click a link and you load a page, you want to load the content of the page as well as any page that page could call (async)?
Edit: So it looks like you can pass "webpackChunkName" to the import statement so that the chunk is given a static name and not a dynamic number. ex. lodash.bundle.js
instead of just [id].bundle.js
https://webpack.js.org/guides/code-splitting/ take a look at the src/index.js portion.
Hello! As you can see in resolve reference in Docs, you shouldn’t start with dot and slash in path.resolve.
Your path in output setting should be: path: path.resolve(__dirname, “build”),
Webpack will do lazy module loading when you put a require() or import() inside your code as opposed to on the top of the module file. When you have lazy module loading it will create a separate chunk that will dynamically be loaded at runtime when you hit that line of code. https://webpack.js.org/guides/lazy-loading/
In any case, you will have to build some abstraction to make it work. In my case, I had to provide a public path ie. /
(https://webpack.js.org/configuration/output/#outputpublicpath) to the package that matches the public path of the Consumer app.
>What specific issues are you having with regard to UMD?
When I was serving an html file as follows:
<html>
<head>
<script src="my-output-lib.js"></script>
</head>
<body>
<div id="div-to-be-manipulated"></div>
<script>
myOutputLib.init();
</script>
</body>
</html>
... the console had been giving me the following error:
react-jsx-runtime.development.js:85 Uncaught TypeError: Cannot read property 'SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED' of undefined at eval (react-jsx-runtime.development.js:85) at eval (react-jsx-runtime.development.js:1220) at Object../node_modules/react/cjs/react-jsx-runtime.development.js (my-output-lib.js:39) at __webpack_require (my-output-lib.js:103) at eval (jsx-runtime.js:4) at Object../node_modules/react/jsx-runtime.js (my-output-lib.js:49) at webpack_require (my-output-lib.js:103) at eval (index.tsx:8) at Object../src/index.tsx (my-output-lib.js:59) at webpack_require (my-output-lib.js:103)
However, it just dawned on me what is probably going on here. I had had the setting"jsx": "react-jsx"
in my `tsconfig.json` compilerOptions, and this was causing the output file to retain incompatible syntax when loaded into the browser. When I switched it to "jsx": "react"
, everything seems to work as desired. So, problem solved I think. Thanks!
BTW/FYI -- not sure what you had in mind when suggesting I need to include `export default {}
`. I have no default export, and everything seems to work the way I wanted it.
People are suggesting ESLint/TypeScript which is where I went too, this is what a linter is for.
It is worth noting that you can run lint in webpack
Webpack actually relies on Terser for dead code elimination.
You can confirm this by comparing treeshaking results on a builds with and without Terser enabled.
​
For finding unused functions/variables, just use ESLint.
Webpack basically tells you that it cannot load PNG file without an appropriate loader.
Previously (webpack <5), file-loader was used but its is now depreciated.
Since webpack v5, you should use resources assets for that.
You need to understand the basic principles of JavaScript modules.
Check out the getting started docs with webpack
https://webpack.js.org/guides/getting-started/
And about modules
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Modules
Happy new year!
You might have to add output.library, if you've already imported the files in script.js. This sets the global name for your library if you wish to access it on window.
You're looking for the output.publicPath option.
https://webpack.js.org/configuration/output#output-publicpath
The stackoverflow question you found is not related to your issue, as that is about resolving paths at compile time, whereas your issue is about resolving paths at runtime.
>maxSize is only a hint and could be violated when modules are bigger than maxSize or splitting would violate minSize.
It seems your source is written in such a way that webpack is unable to split that specific part up in a smaller size.
Your code, once output, does not need to be readable by humans. It needs to work which is something Babel does well.
Supporting multiple outputs in different locations is quite literally one of the things Webpack does best. I truly do not mean to be condescending - have you read this section: https://webpack.js.org/concepts/ ?
Specifically in regards to entry, loaders, and outputs? Your solution is simpler, but you're ignoring what I said before: Webpack is not meant to compile a few files in a single folder. It offers the most value to developers who are working with multiple filetypes, which collectively create large dependency graphs. For example, if you wanted to use SCSS in your JSX files, I don't believe Babel would support that - what then? And what if you hypothetically wanted to import an SVG into your JSX file without it being inline? And if you also wanted Hot Module Reloading so that your page updates without needing a refresh? These things need to happen on dev as well as for a production build.
Webpack offers these things and more. You cannot really accurately assess Webpack's usefulness when you're only doing one simple type of task (e.g. compiling JSX -> JS).
yes and correct me if I am wrong but as far as I understand it does not solve the two issues I previously mentioned .
the compiled js files contain a lot of webpack code and they are unreadable (my code is a string inside an eval) ,
webpack does not watch newly created files so I have to kill the watch and rerun it every time I create a new jsx file
Each entry point is intended to be used independently, ideally one per page. Likely you have webpack automatically create your html files including the script tags for entry points, but if you're manually creating script tags or loading files by name, these name keys are important. They are used in conjunction with the output.filename
configuration. See https://webpack.js.org/guides/output-management/
If you wanna do that _the webpack way_ you might want to consider using the ProvidePlugin https://webpack.js.org/plugins/provide-plugin/
​
Otherwise you can also do `window.test = test` on your controller
>Isn't anything not inside a function or statement a global object?
No. You have global scope, module scope, function scope and block scope. For example, you can have different functions test
in different modules without polluting global scope.
>has webpack a special way of attaching global objects?
Yes, but that is not good practice in most cases. You can use expose-loader
, or build a library
Is there a reason you can’t use separate source map files with the devtool: ‘source-map’ option?
With the ‘source-map’ configuration, just host your source maps in a static files directory. If the auto-generated sourceMappingUrl directive doesn’t line up exactly, you can just right click on the script in devtools and select the “Add Source Map” option from the context menu. Just put the absolute url to the desired source map and it’ll work.
Last, for more fine-grained control over source maps, check out the SourceMapDevtoolPlugin: https://webpack.js.org/plugins/source-map-dev-tool-plugin/
Oh also, if you’re writing typescript, you need to enable the sourceMap option in your tsconfig.json. It lives under the compilerOptions key.
>what do I need to do to get the CSS / JS files to load?
You don't need to do anything, webpack-dev-server establish an web-sockets connection with your app (by adding some code for it) and live-reloads your page whenever you change entry
​
> I cant figure out for the life of me why it is not being loaded.
I suggest you going through the getting-started guide, and check your set-up step by step.
​
It's needed to invalidate browser cache for the file when it is updated on the server.
It solves the following issue. Assume you updated your main.js file content and upload a new version to the server. But when a user open your site, browser won't download your new main.js with new content, because it's cached. The problem won't happen if your main.js is named like main[hash].js where [hash] is a hash generated based on main.js content. Because even if you change one symbol in your main[hash].js file the [hash] string will be different.
​
I ended up following the sass-loader instructions almost exactly:
const path = require('path');
module.exports = { entry: './src/index.js', mode: 'development', output: { filename: 'main.js', path: path.resolve(__dirname, 'dist'), }, module: { rules: [{ test: /.scss$/, use: [ 'style-loader', // creates style nodes from JS strings 'css-loader', // translates CSS into CommonJS 'sass-loader', // compiles Sass to CSS, using Node Sass by default ], }], }, };
I haven't started using separate prod / dev configuration files yet, but I have read webpack's Production guide which is similar to your configuration.
To me it looks like webpack is handling my dependencies. I know they're referenced in the source, but the lines that reference them are only understood by webpack and that source file is only identified in webpack.config.js
as the entry
. If I wasn't using webpack, I'd have tags in my HTML for each dependency. Right now, the only dependency I'm handling in the HTML is the bundle file generated by webpack. I guess it's just a different perspective that comes from lack of experience with webpack.
I read the source for all the loaders I use. However, their docs have this page: Writing a Loader.
One easy solution could be to parse the HTML with something like JSDOM. Then you could transform things as if you were using a browser.
I've tried , it might not work that way?
I've come up using the script loader like :
const jQuery = require('script-loader!./libs/jquery-3.1.1/jquery-3.1.1.min.js');
this is a way provide by the doc https://webpack.js.org/guides/shimming/
It doesn't really make good use of the dependency management of webpack I think , but maybe that's all I can do to a non-module lib?
Checkout https://webpack.js.org/guides/code-splitting-libraries/ and especially the CommonsChunkPlugin
This config will output app.js, app.css, node_modules.js, and node_modules.css
entry: {app: 'src/app.js'},
output: {
path: outputDir,
filename: '[name].[chunkhash].js',
},
loaders: [{
test: /.css$/,
loader: extractText.extract({...})
}],
plugins: [
new extractText({
filename: '[name].[chunkhash].css',
}),
new webpack.optimize.CommonsChunkPlugin({
name: 'node_modules',
minChunks: module => module.context && module.context.indexOf('node_modules') !== -1,
})
]
Another thing to note is to use dynamics labels for output files: [name].[chunkhash].js/css