Webpack Encore: Frontend like a Pro!

Hey Yuri Plashenkov!

Ah, I see that! Yea, the manifest.json file is only needed if you need to refer to built assets from a Twig file - most probably an image that used Encore to copy into the build directory - e.g. <img src={{ asset('images/foo.png') }} - in that case Symfony will look for "images/foo.png" in the manifest.json file (assuming you have this configured in assets.yaml). But it's not really needed otherwise (it WAS used in an earlier version of WebpackEncoreBundle, but it's really not important now). In a perfect world, we maybe shouldn't concern ourselves at all with "asset packages" when we use the encore_entry functions. And as you mentioned in your issue, yes, "asset packages" and "builds" are *completely* different things... and you likely don't need multiple asset packages.

So yea, that 2nd arg about the asset packages is a little "not smooth" ;), but I hope this helps. We could maybe considering removing it in a future version, but that's tough to do without breaking backwards compatibility.

Cheers!

Hey Ryan,
Thank you for your answer!
Yes, it looks like I've got it already. If you use Encore, you do not need to think about assets and packages at all. It should not use manifest.json, because it will use entrypoints.json. The problem is encore_entry_link_tags() tries to load default manifest.json specified in Symfony config (and it is specified there by default), and we get an exception. Even if null is passed as the second parameter. And we have to find out what's wrong, find it in config and disable. I've expressed all my first confusion here: https://github.com/symfony/...
Now it looks more or less clear to me, but I still think that something is super complicated with all these parameters. :)

Hey Yuri Plashenkov !

Yea, that second parameter is super unuseful. I added it to cover an edge case... but I'm not sure that edge case is even needed. So, to simplify, I would basically ignore that 2nd argument - pass null to it. So basically, you if you've configured multiple builds (it sounds like you have), then you have multiple builds... and that's it :).

That's sort of a non-answer, but it's (honestly) probably not that interesting to get into the real detail of these "packages" things. They are part of symfony/asset and aren't particularly useful when you're processing everything through Encore. It holds the 2nd argument because I coded for that edge-case first... and then later someone added the "multiple builds" feature to Encore.

Cheers!

Hey!

What's the purpose of the second parameter in encore_entry_link_tags()? It looks like it tries to use packages from assets. If I use multiple webpack configs, and I've configured webpack_encore.builds in webpack_encore.yaml — it's clear, encore_entry_link_tags() reads corresponding entrypoints.json. But it also tries to read wrong manifest.json file specified by default in assets.yaml. It's very complicated. Builds... Packages... I'm lost. When I configure my Encore, I get only builds, and they contain both (entrypoints and manifest) JSON files, and it looks like one thing to me. But why are there two different parameters in encore_entry_link_tags()?

I highly recommend you to use Encore in your Symfony projects, it just make things a lot easier :)

I'm fairly clear about that, I just tested using the old asset method and worked fine, for now I'm just playing with some things I wanted to learn to do, so decided to not explore something else new while I finish learning those relations things from doctrine which I want to learn first, once I have mastered that,its very likely ill explore encore.

Hey JLChafardet

Using Webpack Encore is the prefered way of Symfony for handling assets but I believe you can use any other mechanism that fit your needs. Symfony does not obligates your to use Encore :)

Cheers!

this seems to be a fun and likeable skill to learn, but what about our old "asset" way of handling simple assets? is it discontinued, or added into the core of symfony? to call images, css, javascripts, etc?

Hey Dave,

Hm, I see... For me it sounds like "eslint-loader & babel-eslint" are optional dependencies, they are required only when you use configureLoaderRule(). This way Encore does not want to force everyone pulling those packages as some customers might just not needed them. So maybe it's only listed in dev deps in package.json for clarity, or maybe it's used in some tests also.

Anyway, good idea to open an issue I think. Probably someone will be able to explain how it works with babel-eslint behind the scene better than I did.

Cheers!

Hi Victor,


/var/www/api-platform # yarn why babel-eslint
yarn why v1.16.0
[1/4] Why do we have the module "babel-eslint"...?
[2/4] Initialising dependency graph...
[3/4] Finding dependency...
[4/4] Calculating file sizes...
=> Found "babel-eslint@10.0.3"
info Has been hoisted to "babel-eslint"
info This module exists because it's specified in "devDependencies".
info Disk size without dependencies: "2.4MB"
info Disk size with unique dependencies: "6.18MB"
info Disk size with transitive dependencies: "13.52MB"
info Number of shared dependencies: 27
Done in 0.79s.

so it's only a dependency because I added it. If I don't add it:

Running webpack-dev-server ...

WARNING Be careful when using Encore.configureLoaderRule(), this is a low-level method that can potentially break Encore and Webpack when not used carefully.
Error: Install eslint-loader & babel-eslint to use enableEslintLoader()
yarn add eslint-loader@^2.1.2 babel-eslint@^10.0.1 --dev

error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.


So it looks like it's a required dependency by webpack as it's the default parser even though it may not be used. I'll post the question on their github wiki. Thanks!

Hey Dave,

I don't know the exact reason but probably could give you some tips. First of all, JS dependencies are weird :) Really, when you run "yarn install" tons of tons JS packages are pulled locally. So, some dependencies still might require it. Also, you can give some hints from Yarn on it, try to execute "yarn why babel-eslint" to know why exactly it was installed. Does the output helps? Let me know if it's not. Btw, what exactly error message do you see when you don't have "babel-eslint" package installed?

Btw, I also noticed "babel-eslint" as a dependency in package.json of Webpack Encore, see https://github.com/symfony/... . So, it looks like a required dev dependency of Webpack Encore

Also, probably this issue could answers some questions for you? https://github.com/symfony/... . Otherwise, probably better to ask this question on webpack encore repo, probably someone there could answer this question better than me.

I hope this helps!

P.S. Thank you for your kind feedback about our courses! And congrats on your first headless app, well done!

Cheers!

I wasn't sure where to ask this question, I didn't want to add it as a encore github issue because it's probably not an issue but just me.

What i'm trying to use is encore, typescript, react, and linting typescript with using the '@typescript-eslint/parser' parser (since tslint is being deprecated). I got it all working, but my question is why do I still need the 'babel-eslint' package if i'm not using the babel eslint parser? Encore complains that I need it if I enable 'enableEslintLoader'. Here is the relevant parts of my webpack.config.js:

    .enableTypeScriptLoader()
    .enableForkedTypeScriptTypesChecking()
    .enableEslintLoader(options => {
        options.parser = '@typescript-eslint/parser'
    })
    .configureLoaderRule('eslint', loader => {
        loader.test = /\.(jsx?|tsx?)$/
    })
    .enableReactPreset()

Here is the relevant parts of my .eslintrc.js file:

    parser: "@typescript-eslint/parser",
    plugins: [
        "@typescript-eslint",
        "react"
    ],
    extends: [
        "eslint:recommended",
        "plugin:@typescript-eslint/eslint-recommended",
        "plugin:@typescript-eslint/recommended",
        "plugin:react/recommended"
    ],
    parserOptions: {
        ecmaVersion: 2018,
        sourceType: 'module',
        ecmaFeatures: {
            jsx: true
        }
    }

Oh also the 'fork-ts-checker-webpack-plugin' now supports eslint, however when I enable it with:

    .enableForkedTypeScriptTypesChecking(tsConfig => {
        tsConfig.eslint = true;
    })

it doesn't seem to do anything. So i'm just wondering what I'm missing, or what's the best way to config eslint & typescript parser. Thanks in adance, your videos for react and api-platform has given me a huge head start in building my first headless app!

Hey Xidoc,

Could you explain more what exactly problem do you have? Any error messages that would help to figure out your problem? What exactly you want to configure? Did you follow any installation guide or docs? We would be glad to help you knowing a little more about your problem

Cheers!

How can I configure Foundation ?
I don't understand where is the problem ?

Hey Shamshid!

That's an excellent suggestion - I haven't played much with purge, but I've heard of it. I think getting it to work nicely requires (as you guessed) a bit of work... and I'm not sure it's worth it. I know Javier played with it for a bit, but ultimately decided not to use it. Here are some resources: https://github.com/symfony/... and https://github.com/symfony/...

Cheers!

great tutorial.

You should bring usage of purgecss in Encore which will trim out unwanted css and most importantly we need to learn to make a config to which trims page specific css from dedicated css file. (kinda confusing what I told here)

"pack" of knowledge 😂- yep, we're friends :D

Hi Ryan, thanks for another amazing and hyuooOOOooough! huge pack of knowledge.

Thanks for your answer Diego Aguiar
I am waiting the course,

Cheers!

Hey Alex Zerah

First to clarify, this course is not about Jquery, but it's a very accepted library for the community, and there are many tricks you need to know about how to properly integrate it with Encore (and this is even more needed when working with Jquery plugins that are poorly written)

Cheers!

This seems very great!

Something is bothering me.
Why are you using jQuery? I am not saying it's not a good tool. If well configured the library can be awesome. But vanilla JS is powerful enough today to be used alone.