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.
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?
require would be a notch safer as it would allow validation
postcssOptions
{ "postcss-nested": { preserveEmpty: true } } in the future
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.
minimze: true just once for overall config? or for each plugin, with that ... "syntax"?
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
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 ^
@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::
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.
@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.
volta-cli/volta#651
"... we don't currently support Yarn 2 within Volta itself ..."
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.