Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Mar 15 08:01

    bebraw on dev

    fix: Use webpack-obfuscator chore: Bump version 3.0.4 (compare)

  • Mar 15 08:01

    bebraw on master

    fix: Use webpack-obfuscator chore: Bump version 3.0.4 (compare)

  • Mar 15 08:01

    bebraw on v3.0.4

    (compare)

  • Mar 03 13:43
    heart-er closed #344
  • Mar 03 13:43
    heart-er commented #344
  • Mar 03 13:43
    bebraw commented #344
  • Mar 03 13:42
    heart-er commented #344
  • Mar 03 13:01
    bebraw commented #344
  • Mar 03 12:54
    heart-er commented #344
  • Mar 03 11:23
    bebraw commented #344
  • Mar 03 11:08
    heart-er commented #344
  • Mar 03 08:03
    bebraw commented #344
  • Mar 03 02:05
    heart-er commented #344
  • Mar 03 02:02
    heart-er commented #344
  • Mar 03 02:01
    heart-er commented #344
  • Mar 02 17:20
    bebraw commented #344
  • Mar 02 16:07
    bebraw commented #344
  • Mar 02 15:59
    heart-er commented #344
  • Mar 02 15:51
    heart-er commented #344
  • Mar 02 15:50
    heart-er commented #344
Juho Vepsäläinen
@bebraw
for me, the need to purge css feels like an anti-pattern - it shouldn't be needed
Huna M
@Huna_gitlab
Yeah, I'm thinking the same thing. AND, not using it "solves" my problem(s)!

using postcss with webpack5, I find general usage online for adding plugins of both

loader: 'postcss-loader',
options: {
    postcssOptions: {
        plugins: [
            [
                'precss',

and

-                'precss',
+                require('precss'),

When is the require preferred, or itself required?
When to use one vs the other?

Juho Vepsäläinen
@bebraw
i know that postcss-loader api changed at one point. i'm not sure if there's a big difference in this case and it's possible it works with both ways
i think if you have your linter set up the right way, then using require would be a notch safer as it would allow validation
at least in the docs they prefer the string or object (with options) form
Huna M
@Huna_gitlab
So 'require(...)' for each/every plugin is tolerated?
Juho Vepsäläinen
@bebraw
likely it will error if it doesn't work :)
it seems they'll deprecate { "postcss-nested": { preserveEmpty: true } } in the future
Huna M
@Huna_gitlab
Wow. Not exactly the most consistent docs!
Juho Vepsäläinen
@bebraw
it's a bit tricky with each loader/plugin sometimes, yeah
Huna M
@Huna_gitlab

Does 'the book' reference "..." syntax?
As in
"For webpack@5 you can use the ... syntax to extend existing minimizers"
?
I've created two webpack parts, one to minify JS, the other to minify CSS.
each can/does reference

    optimization: {
        minimize: true,
        minimizer: [
        new <PLUGIN>

Looking for clarity as to how you 'stack' these.

i.e., do you set minimze: true just once for overall config? or for each plugin, with that ... "syntax"?
Juho Vepsäläinen
@bebraw
@Huna_gitlab ... means there can be more code
so it's not code itself :smile:
it's only a book convention
Huna M
@Huna_gitlab

heh. ok. so can

optimization: {
        minimize: true,

be reliably (un)set per-plugin?

Juho Vepsäläinen
@bebraw
@Huna_gitlab the way i read it, it's a global setting for all
somehow this configuration became more complex in webpack over time
earlier minification was just plugins
right, so reading from https://webpack.js.org/configuration/optimization/#optimizationminimize it's simply a toggle to define if the plugin should be used or not. from my point of view it's a redundant option as i solve toggling things through merging :smile:
NickWoodward
@NickWoodward

Hello!

I'm about to switch from regular html to a template engine (probably ejs), and I just thought I'd ask in advance what I should expect to go wrong? :D

Is it just as simple as passing HtmlWebpackPlugin the ejs file instead? (webpack 4 btw)

Thanks!

Juho Vepsäläinen
@bebraw
@NickWoodward what's your use case?
with html-webpack-plugin or mini-html-webpack-plugin it's fairly simple to use any js templating engine you prefer so that it's easy to inject custom content per page
NickWoodward
@NickWoodward

Ah sorry @bebraw, I missed your reply!

I'm fairly new to deploying sites and had developed a frontend with vanilla JS, and a pure REST backend (so completely separate).

I haven't been able to get any answers on whether it's ok, say on an Admin page, to just use authorisation to protect the route on the backend, but not worry about access to the front end. IE: anyone can navigate to www.example.com/admin.html, but that page won't display sensitive data because of the backend authorisation .

So I thought I'd convert the site to a single backend server that renders the html itself (res.render('pathTo.ejs', {data})) using a template engine. That makes the authorisation cover both the data and the html.

At the moment my plugin just looks like this:

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

So I was hoping I could just switch out the file and template name. I'd try it out myself, but haven't built it yet. Just wanted to know if it was straight forward.

Sorry if this seems confused - I've probably got my mental model of all this completely wrong!

Appreciate any help but understand if you want to dodge the wall of text! :D

Juho Vepsäläinen
@bebraw
@NickWoodward no probs. i've covered a potential approach at https://survivejs.com/webpack/output/multiple-pages/
you would still need to set up auth and all that on your server but that's how you could generate multiple different pages with webpack quite easily
it's not the use case where it shines, though, but it's possible to do it
something like https://www.11ty.dev/ is far more optimized for this kind of usage
NickWoodward
@NickWoodward

Ah, I've got the multi page aspect of it working well thanks (I remember that page well!)

I think, now that I've written it all out above, there shouldn't actually be much of a difference with ejs files - I'll give it a try :)

Regarding the authorisation - do you understand what I'm getting at RE the page you navigate to allowing unauthorised access, but the data that page retrieves requiring authorisation? IE there's no authorisation on the frontend to get to the admin page, but the data is protected? I can't find any info on it, which makes me think it's not a valid approach?

TBH I'd much rather stick with that ^

Juho Vepsäläinen
@bebraw
@NickWoodward for auth, you could have a bit of js logic around the queries that shows the user access has been denied. i think there are many ways to do it
platforms like netlify also handle this somehow these days so you can have individual pages behind an auth step
NickWoodward
@NickWoodward

@bebraw yeah I think I might just use a combination of hiding any navigation to the admin page + redirects to those who aren't authorised.

so if you aren't the admin you can't see the link, but you can still navigate there manually using the URL. But if you do that, the backend route redirects you to the homepage if you aren't authorised. worst case scenario they can navigate to an empty admin page without authorisation by turning off JS

does that sound relatively secure/sensible? can't really believe this isn't talked about more - i guess most people use pure REST api's for react ::shrug::

Juho Vepsäläinen
@bebraw
yup, that sounds good to me
i guess it's one of those topics that's somehow on top of others so specific resources don't discuss it so much
NickWoodward
@NickWoodward
Good to know that someone who knows what they're talking about thinks it's not a stupid approach - thanks!
Huna M
@Huna_gitlab
Anyone had any experience/luck migrating a full/complex Webpack5 config from yarn1 -> yarn2? on yarn1, all's perfect with a SurviveJS-tutored split config, etc. Really quite nice!
Install of Yarn2 is easy enough. But 'same site', either migrated to, or clean installed on, yarn2 -- with or without PnP -- is just chock full of linting errors, etc.
Wondering if it's still too early, and I'm spinning my wheels.
Juho Vepsäläinen
@bebraw
@Huna_gitlab i haven't tried yarn 2 yet. can you update your github project and link me to it so i can try?
it's probably a good chance for me to try https://volta.sh/
Huna M
@Huna_gitlab

@bebraw I'll work on reducing this production monster to something that's a good demo and push it.

Never heard of 'volta'! Supposed to be a complete replacement for yarn/npm?

the yarn2 experience, so far, has me wondering whether a shift back to npm -- despite or because it's Microsoft now, I dunno -- is called for.

Huna M
@Huna_gitlab
@bebraw fyi, depending on what your goal is,
volta-cli/volta#651
"... we don't currently support Yarn 2 within Volta itself ..."
Juho Vepsäläinen
@bebraw
oh, wow. that's good to know
i was thinking this would be a nice way to manage yarn 1/2 on a system
the idea behind volta is to give control over version of node/npm/yarn you are using as there are subtle differences
Huna M
@Huna_gitlab
@bebraw
too many package managers! :-/ adding layer upon layer of opinionated abstraction is a PITA. 4 me, that's why I refuse to use webpack 'wrappers' like in Symfony or Laravel frameworks.
yarn1's at least been quick and (mostly) stable. tbh, I can't convince myself of its status atm: abandoned? deprecated? maintenance? active?
seems like most of the dev focus has gone to yarn2 already.
in my experience, so far, it's too early. because either the docs are thin, the code's not ripe, ecosystem support is lacking, or some some combo.
Juho Vepsäläinen
@bebraw
yup. in a client project we've been happily using yarn 1 and in other contexts it's still npm 6
npm 7 is still fresh so i'm a bit wary of using it
i agree it's a bit confusing situation atm with all the package managers and versions
it's not usual that you have two big versions of each in use