Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Aug 12 18:09
    dependabot[bot] labeled #349
  • Aug 12 18:09
    dependabot[bot] opened #349
  • Aug 12 18:09

    dependabot[bot] on npm_and_yarn

    chore(deps): Bump path-parse fr… (compare)

  • Jul 05 12:12

    bebraw on dev

    fix: Fix syntax fix: Bump version 3.0.6 (compare)

  • Jul 05 12:12

    bebraw on master

    fix: Fix syntax fix: Bump version 3.0.6 (compare)

  • Jul 05 12:12

    bebraw on v3.0.6

    (compare)

  • Jun 14 07:12

    bebraw on dev

    chore: Bump version 3.0.5 (compare)

  • Jun 14 07:11

    bebraw on v3.0.5

    (compare)

  • Jun 14 07:11

    bebraw on master

    improve text with some grammati… chore(deps): Bump lodash from 4… Merge pull request #345 from kc… and 9 more (compare)

  • Jun 14 07:06

    bebraw on dev

    fix: Add a missing comma fix: Use new clean config fix: Fix import (compare)

  • Jun 14 06:55
    bebraw closed #347
  • Jun 14 06:55

    bebraw on dev

    fix: Add escaping to nodemon C… (compare)

  • Jun 14 06:53

    dependabot[bot] on npm_and_yarn

    (compare)

  • Jun 14 06:53

    bebraw on dev

    chore(deps): Bump lodash from 4… Merge pull request #346 from su… (compare)

  • Jun 14 06:53
    bebraw closed #346
  • Jun 14 06:53
    bebraw closed #348
  • Jun 14 06:53

    bebraw on dev

    chore: Thank @kckusal fix: css-loader supports absolu… (compare)

  • Jun 14 06:48
    bebraw commented #345
  • Jun 14 06:47

    bebraw on dev

    improve text with some grammati… Merge pull request #345 from kc… (compare)

  • Jun 14 06:47
    bebraw closed #345
NickWoodward
@NickWoodward
image.png

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
image.png

@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!