survivejs/webpack

Feel free to ask questions related to the book content or webpack here. I'll get to them eventually. Stack Overflow or Reactiflux is likely faster for general questions, though.

NickWoodward

@NickWoodward

Trying to update to webpack 5 after everything broke XD

Following the docs here: https://webpack.js.org/migrate/5/

When it says to upgrade to the latest versions of webpack-cli and plugins/loaders - does it mean the latest major or minor versions?

Juho Vepsäläinen

@bebraw

@NickWoodward major versions. many of the plugins have webpack 5 support in major only and in some cases they drop webpack 4 support in those as well

the api difference is quite small though packages like webpack-cli have changed their api surface

i like to use https://www.npmjs.com/package/npm-check-updates for figuring out what has updated and then applying the updates

NickWoodward

@NickWoodward

Thanks @bebraw. I'll try and work through it tomorrow

Juho Vepsäläinen

@bebraw

cool. let me know how it goes or if there are any specific errors

NickWoodward

@NickWoodward

@bebraw will do, thanks. Had my second jab ^that day and it knocked me on my arse so didn't make much headway.

I did discover that even updating to the latest version of 4 (and minor versions of plugins) caused errors with (I'm assuming) my svg loaders. Had previously thought it was an issue migrating to 5, but might focus on fixing 4 for the time being if you don't mind taking a look?

ERROR in Error: Child compilation failed: Module not found: Error: Can't resolve './svg/spritesheet.svg' in 'C:\Users\Nick\test\JJ\webpack5Test\Recruitment-Frontend\src': Error: Can't resolve './svg/spritesheet.svg' in 'C:\Users\Nick\test\JJ\webpack5Test\Recruitment-Frontend\src'

Updating gives lots of errors, all based on not being able to resolve spritesheet.svg above ^. My confusion is that the spritesheet has never been in the src folder - I use svg-sprite-loader to extract single svgs into a spritesheet, and it's worked fine.

// webpack.common.js

const HtmlWebpackPlugin = require('html-webpack-plugin');
const SpriteLoaderPlugin = require("svg-sprite-loader/plugin");


module.exports = {
    entry: {
        common: './src/js/common.js',
        index: './src/js/index.js',
    },
    module: {
        rules: [
            {
                test: /\.js$/,
                use: 'babel-loader'
            },
            {
                test: /\.html$/,
                use: 'html-loader'
            },
            {
                test: /\.svg$/,
                use: [
                    {
                        loader: 'svg-sprite-loader',
                        options: {
                            extract: true,
                            spriteFilename: 'svg/spritesheet.svg'
                        },
                    },
                    'svgo-loader',
                ]
            },

        ]
    },
    plugins: [
        new HtmlWebpackPlugin({
            filename: 'index.html',
            template: './src/index.html',
            chunks: ['index', 'common']
        }),
        new SpriteLoaderPlugin(),
    ]
}

*apologies for the wall of text!

Juho Vepsäläinen

@bebraw

@NickWoodward can you set up a repository with a minimal example to run? i have a feeling it has to do with that specific loader

NickWoodward

@NickWoodward

@bebraw yeah I think you're right - I struggled with 'svg-sprite-loader' when first setting this up (was surprised I got it working). Wouldn't be surprised if it's also the problem now.

I probably won't be able to get an example up until tomorrow morning/early afternoon now, but really appreciate the help.

NickWoodward

@NickWoodward

Hi @bebraw, I've sort of managed to set up a minimal example (https://github.com/NickWoodward/loader-test), although I now get 2 errors - the original error about resolving spritesheet.svg, and one about not being able to resolve the module svgo

ERROR in ./src/assets/icons/webpack.svg
Module build failed (from ./node_modules/svgo-loader/index.js):
Error: Cannot find module 'svgo'

& the original error:

Module not found: Error: Can't resolve './svg/spritesheet.svg' in 'C:\Users\Nick\test\webpack-5\src'

I've no idea why svgo-loader is now a problem, it turns out that I'm now using the same versions as my working project (I even installed every dependency in a different branch to make sure I wasn't missing something).

Am just a bit stumped - but the odds are incredibly high that I'm just doing something stupid :D

Juho Vepsäläinen

@bebraw

ok, i'll try quickly

maybe it's not finding the dependency

Juho Vepsäläinen

@bebraw

@NickWoodward there were several smaller fixes to do. see https://github.com/NickWoodward/loader-test/tree/fix/webpack5

JetBrains/svg-sprite-loader#406 explains why that ejs bit is needed

NickWoodward

@NickWoodward

@bebraw thanks for that. yeah it's just weird that it looks like it isn't finding the dependency when (as far as I can see) the set up is the same as my current project

I remember trying that ejs approach and it causing issues - but it's been so long I can't remember why xD. I was trying to have a hashed spritesheet containing all my svgs. At this point, if it works, I don't care how I achieve it now, but doesn't <%= compilation.assets["sprite.svg"].source() %> reference the entire spritesheet?

My current folder structure for svgs is as above, and I can access them using something like: <use xlink:href="svg/spritesheet.svg#location-solid">

I'll have a play around and see if I can get it working this way. Thanks!

(forgot to mention: currently the svg doesn't display using this approach, but I'll give it a try :) )

NickWoodward

@NickWoodward

@bebraw So... It's working great now... but I've no idea why! xD

If you look at the branch confused, I moved back to not using the ejs syntax in index.ejs, and it works. Combine that with your updates to webpack and I'm happy, so thanks a lot! :)

I mean I have absolutely no idea why the loader suddenly needs the html file to be an ejs file if I'm referencing the files like this: <use xlink:href="svg/spritesheet.svg#location-solid">, but I'm just glad it's working!

(just having the file name index.html causes that Can't resolve './svg/spritesheet.svg' error)

Juho Vepsäläinen

@bebraw

@NickWoodward my understanding is that using plain index.html is somehow disconnected from what the loader generates. the ejs based solution uses a lookup to find it

it's some limitation of the combination

NickWoodward

@NickWoodward

@bebraw I have no idea how it's working on my current project then! But thanks a lot - I think I would have struggled to find that fix!

Juho Vepsäläinen

@bebraw

html-webpack-plugin is a bit magical sometimes. that's why i authored https://www.npmjs.com/package/mini-html-webpack-plugin

i don't know if this sprite task would be any easier with it, though

likely what would happen is that you would do about the same in template

NickWoodward

@NickWoodward

To be fair I feel that a lot of the time about webpack more generally :)

Will take a look at that plugin, cheers

Juho Vepsäläinen

@bebraw

yeah, even after all these years there are still surprising things in webpack for me

the tide might be turning towards tools like https://www.snowpack.dev/

Ryan Stegmann

@rstegg

does that have more potential than rollup?

it seems like most foundational tools & frameworks, like create-react-app, and angular, have cemented themselves with webpack. @bebraw you see this potentially changing or becoming obsolete down the line?

Juho Vepsäläinen

@bebraw

it feels like something fundamental

one interesting movement is happening on the language side. the js tools of the future aren't written in js anymore

swc is a great example of that

it's already displacing babel in some contexts

esbuild (go) is another good example

swc is built with rust and deno also leverages it a lot

https://vitejs.dev/ is interesting btw. it's a rollup distribution more or less

Ryan Stegmann

@rstegg

what are the benefits of improving upon webpack?

all i can really think of is build speed

Juho Vepsäläinen

@bebraw

build speed is an obvious thing, yeah - you can be looking at a magnitude or two of improvement there

also simpler architecture - in its own way webpack is bloated and it can be difficult to work with when you want to do something more custom

Ryan Stegmann

@rstegg

:+1:

NickWoodward

@NickWoodward

Hi @bebraw, just wondered if you've ever used image-webpack-loader? It seems to be compressing the hell out of a background image I manually put a filter on, but I can't see how to exclude the file

Pretty sure I've seen at least one image loader that can do this, but with my skills I don't really want to start messing with my webpack set up too much XD
(I'd rather fix my parallax problem that's making a css gradient not work properly...)

Juho Vepsäläinen

@bebraw

@NickWoodward no but exclusion might be doable through webpack config

my preferred solution for handling images is to push it to some service (cloudinary, imgix, etc.) as doing image manipulations during compilation can feel wasteful

with an image api they can do everything for you (resizing, quality, and so on)

NickWoodward

@NickWoodward

Ah interesting, I hadn't really considered doing that. Might be the way forward given I can't even really remember which loader is deals with images when they're urls in the css (assume it's my url-loader). It's kind of my problem with webpack, I just deal with it so infrequently that it never quite sticks XD

I guess I actually am getting better at it, just real slowly :D

Thanks for the advice!

Where communities thrive

People

Repo info

Activity