Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • May 02 2020 14:55
    matteobortolazzo commented #448
  • May 02 2020 05:40
    bebraw commented #448
  • May 01 2020 21:03
    matteobortolazzo commented #448
  • Feb 02 2019 22:45
    danielhamngren opened #448
  • Nov 18 2018 04:43
    McWatt commented #447
  • Sep 27 2018 18:26
    bebraw commented #447
  • Sep 27 2018 17:45
    jordancclive opened #447
  • Mar 13 2018 16:18
    skarlinski commented #446
  • Mar 13 2018 15:33
    bebraw commented #446
  • Mar 13 2018 15:32

    bebraw on master

    fix(language-features): Drop we… Removed redundant spread operat… Merge pull request #446 from sk… and 2 more (compare)

  • Mar 13 2018 15:32

    bebraw on v2.5.13

    (compare)

  • Mar 13 2018 15:32

    bebraw on dev

    chore: Bump version 2.5.13 (compare)

  • Mar 13 2018 15:29

    bebraw on dev

    Removed redundant spread operat… Merge pull request #446 from sk… (compare)

  • Mar 13 2018 15:29
    bebraw closed #446
  • Mar 12 2018 17:50
    skarlinski opened #446
  • Mar 07 2018 14:47

    bebraw on dev

    fix(language-features): Drop we… (compare)

  • Mar 07 2018 14:46

    bebraw on dev

    chore: Thank @skarlinski chore: Bump version 2.5.12 (compare)

  • Feb 26 2018 08:55
    bebraw commented #445
  • Feb 26 2018 08:54

    bebraw on master

    Changed `const` to `let` in es6… Merge pull request #445 from sk… chore: Thank @skarlinski and 2 more (compare)

  • Feb 26 2018 08:54

    bebraw on v2.5.12

    (compare)

pgnd
@pgnd

I've a 'main' webpack entry point, which @imports an external url css (typekit).

In dev mode it DUPLICATES the import; in prod mode (i.e., with add'l minify), it does not.

Reading up @ SurviveJS on use of PurgeCSS @

https://survivejs.com/webpack/styling/eliminating-unused-css/

to "remove unused CSS", I don't think it's for solving this problem ...
I'm not removing UNUSED css -- I'm trying to prevent duplicating USED css.

What's an option for de-duping that output -- in dev mode -- without minifying?

The asset layout is,

assets/js/main.js
  import '../scss/main.scss';
  ...

assets/scss/main.scss
  @use 'base';

assets/scss/base/_index.scss
  @forward 'base0';
  @forward 'typography';

assets/scss/base/_typography.scss
  @charset "utf-8";
  @import url("https://use.typekit.net/xxxxxxx.css");
  ...

in dev mode, with this load config,

exports.loadSCSS = ({ filename, chunkFilename, includePaths }) => {
  const plugin = new MiniCssExtractPlugin({
    filename,
    chunkFilename,
  });
  return {
    module: {
      rules: [
        {
          test: /\.s?[ac]ss$/i,
          use: [
            { loader: 'style-loader',},
            { loader: MiniCssExtractPlugin.loader,
              options: { esModule: false, },
            },
            { loader: 'css-loader',
              options: { sourceMap: true, importLoaders: 2, },
            },
            { loader: 'postcss-loader',
              options: {
                sourceMap: true,
                postcssOptions: {
                  plugins: [
                    'precss',
                    'postcss-import',
                    [ 'postcss-preset-env',
                      { autoprefixer: { cascade: false, flexbox: 'no-2009', grid: false, },},
                    ],
                    '@lipemat/css-mqpacker',
                    'postcss-reporter',
                  ].filter(function (plugin) {
                    return plugin !== null;
                  }),
                },
              },
            },
            { loader: 'sass-loader',
              options: {
                implementation: require('sass'),
                sassOptions: { indentWidth: 4, includePaths, fiber: false, },
                sourceMap: true,
              },
            },
          ],
        },
      ],
    },
    plugins: [
      plugin,
    ],
  };
};

In dev mode, webpack compiles/generates output -> .css, DUPLICATING the typekit css import

public/build/css/main.css
  @import url(https://use.typekit.net/xxxxxxx.css);
  @import url(https://use.typekit.net/xxxxxxx.css);
  @charset "UTF-8";
  ...

If I additionally run it through a minify stage, as in production,

exports.minifySCSS = () => ({
  optimization: {
    minimizer: [
      new CssMinimizerPlugin({
        test: /\.css(\?.*)?$/i,
        parallel: 4,
        sourceMap: true,
        minimizerOptions: {
          preset: [ 'advanced', { discardComments: { removeAll: true, }, }, ],
          plugins: [ [ 'autoprefixer', { remove: false, }, ], ],
        },
      }),
    ],
  },
});

webpack compiles/generates output -> .min..css

@import url(https://use.typekit.net/xxxxxxx.css);header#layout-header{width:100vw}header#layout-header ...

WITHOUT the duplication.

Juho Vepsäläinen
@bebraw
@pgnd can you set up a tiny example i can run and check? i'll have some time next week. i am too busy this week with react finland
i haven't run into the css deduplication problem before so that will require some research
most likely the way i use css is somewhat different to yours
it might even be a bug in webpack itself
assuming you cannot reproduce the issue outside of it
pgnd
@pgnd
@bebraw
I've started trying to migrate my current webpack5 split-config build env to ES6/modules.
Lots of 'fun' :-/ Particularly with the import-vs-require migrations ...
Returning as always to SurviveJS for insight/docs, do any of your SurviveJS demos/docs yet demonstrate an "all ESM" webpack config?
Juho Vepsäläinen
@bebraw
@pgnd which version of node are you using? is typescript an option?
i think all material i have out there is still on old require syntax as that's most compatible. that said, i recall webpack.config.ts should be supported and maybe webpack.config.mjs would work (i haven't tried this one)
in my personal work, i've moved to ESM only but there i don't even use webpack anymore
pgnd
@pgnd

@bebraw
here, my current attempt is a bit more messy:
i'm trying a mv from webpack5+babel+non-ESM(default type: commonJS), to webpack5+swc+ESM(default type: module)
that's with

node --version
    v16.13.0
npm --version
    8.1.0
yarn --version
    3.2.0-rc.5

ah ... now you mention, I seem to recall you'd mentioned moving on.
are you rollup-ing these days? other?

pgnd
@pgnd

oh, and that^ is with yarn3/pnp.

lots of moving parts.

Juho Vepsäläinen
@bebraw
i'm using a custom setup for https://gustwind.js.org/ . it's deno and then esbuild for any js bundling
@pgnd since it's so recent, i imagine webpack.config.mjs might work. i remember seeing some flags in node for enabling module support as well
if i'm interpreting right, mjs is problematic with webpack webpack/webpack-cli#282
likely webpack.config.ts would be most straightforward but then you need TS :)
pgnd
@pgnd
@bebraw
lol. i've heard of none of gustwind, Deno, Twind, or Sidewind. a gr8 reminder that it's impossible to keep up!
yeah, been dancing with .mjs & .cjs. unsucessfully, with wp5. spending all my time fighting the bundler ... it feels like it's bloating fast just getting it to work.
been looking elsewhere (mostly, so far, @ rollup) for alternative.
of course, I'm terribly spoiled with your tutorials @ survivejs, which have kept my webpack-ing humming along nicely for so long :-)
Juho Vepsäläinen
@bebraw
gustwind/sidewind is my own personal tech. twind is an adaptation of tailwind from some friends. it's completely niche tech :)
if you can reduce your current problem to a small repo to look at, i can clone and likely resolve
pgnd
@pgnd
@bebraw really scratching your own itch, eh? -- nice!
Here's a related repo I using over in a discuss in yarn3 discord: https://github.com/pgnd/yarnesmtest
The initial task was to 'just' add globby v>=12, which is ESM-only. That led to learning that ALL require need to then mv to import -- and the fun started.
That, of course, is just a simple repo ... that I didn't manage to get converted to all ESM etc.; looking at my production wp5 config, which is a lot more involved, got me looking into other bundlers.
And, webpack project feels like its stretched way too thin across too few devs. There's a few really talented folks that are just slammed -- and bugs/issues are piling up faster than they can get resolved.
Juho Vepsäläinen
@bebraw
yeah, it's a big project and a lot to maintain
the site generator is all about simplifying my future efforts. one of the cool features is that it's self-hosting in sense that i can edit the pages on the site itself (early prototype) so in theory i could push this to a point where i can develop simple sites on top of web site itself but getting that far will take more engineering
the basic structure has been designed this in mind and i have an early version of a page editor in place
i also put effort into making it go well with workers so larger builds should go fast
just having a look at your repo
pgnd
@pgnd

the site generator is all about ...

I need to readup on Deno et al and catch up a bit!

should go fast

similar performance improvements to swc vs babel?

Juho Vepsäläinen
@bebraw
deno is using swc underneath
Juho Vepsäläinen
@bebraw
it seems .mjs just works though you have to be careful about some things like file naming and __dirname. there are also a couple of minor todos
pgnd
@pgnd

yeah, discovered the __dirname workaround already.

.mjs "just works" as ... webpack.config.mjs/webpack.parts.mjs?

Juho Vepsäläinen
@bebraw
yup, naming is important
it looks like node doesn't need any custom flag to work in v16
pgnd
@pgnd
hm. i certainly wasn't having much luck ... buried in lots of build-time errors.
perhaps i'll revisit ... after a trial-spin with rollup
Juho Vepsäläinen
@bebraw
how did it fail?
https://vitejs.dev/ is interesting. it's using rollup under the hood
pgnd
@pgnd

lots of various errors ... modules not found, import not usable, etc. i'm sure it was 'me' ...

Thanks for the mods @ repo -- I'd completely missed the default export! That helps ...

vitejs ... yet another new one on me. reading up as to why 'on top of' rollup, vs 'just' rollup ...
pgnd
@pgnd
::lightbulb:: !
import * as parts from "./webpack.parts.mjs";
pgnd
@pgnd

@bebraw

got most of my webpack config mv'd to ESM support.
thx for the pointers - really helpful!

re: your comment @ repo,

// TODO: Get mode from argv

this

const getConfig = (env,argv) => {
    let mode = argv.mode;
    console.log(`\n###### mode == ${mode} ######\n`);
    switch (mode) {
        case 'production':
            return merge(commonConfig, prodConfig, { mode });
        case 'development':
            return merge(commonConfig, devConfig, { mode });
        default:
            throw new Error(`Trying to use an unknown mode, ${mode}`);
    }
};
export default getConfig;

seems to work for --mode=... cmd line arg, e.g.

yarn webpack --mode=development
unclear still what one does with require.resolve, in tests, e.g.,
https://survivejs.com/webpack/techniques/consuming/#exposing-globals-to-the-browser
pgnd
@pgnd

per
https://nodejs.org/api/esm.html#esm_no_require_resolve

looks like at least

import {resolve} from 'import-meta-resolve';

is req'd for ESM

but don't yet know to leave, or change, the
test: require.resolve
to an await ... etc.

pgnd
@pgnd
createRequire (https://pvdz.ee/notes/184) works as an interim alternative, leaving the test: require.resolve... in place
Juho Vepsäläinen
@bebraw
ah, that's a good one. thanks. i think i'll port the book to ESM in the next bigger pass
content-wise there isn't much to add but it feels like ESM is starting to become the standard even for node code
pgnd
@pgnd

@bebraw a number of 'popular' pkg devs are moving to ESM-only full-steam-ahead. i can't say i blame them much for forcing the issue, but it does cause breakage. ESM-only, or at least ESM-"first" is coming ...

Docs are still really thin for getting the details worked out , particularly re: migrations (e.g., with this test: require.resolve biz ...). for new installs, one can more easily stumble into a working setup.

Juho Vepsäläinen
@bebraw
yup, that's a good point and also a good argument for doing an ESM specific pass on the book content :)
pgnd
@pgnd

@bebraw

re:

"Consuming packages outside of webpack"
https://survivejs.com/webpack/techniques/consuming/#exposing-globals-to-the-browser

&

ESM specific pass on the book content

, handling jquery is still/currently messy,

ESM distribution / exports in package.json 
https://github.com/jquery/jquery/issues/4592

    "I've added the Blocker label to it since adding exports is a breaking change so we need to do it in 4.0.0."

here,

    yarnlist jquery
    └─ jquery@npm:3.6.0

& unclear when v4 is planned

Clarify jQuery 4 plans
https://github.com/jquery/jquery/issues/4421

Any docs/examples,particularly with "type": "module", as default, would need to accommodate jquery as !ESM.
might be a bad, thorough example to use, actually ... particularly to get/keep shaking working.

Juho Vepsäläinen
@bebraw
thankfully jquery isn't used so much in new projects anymore :)
pgnd
@pgnd
still more than you might think/hope!