110 Matching Annotations
  1. May 2023
  2. Mar 2023
    1. Fortunately with webpackChunkName in an inline comment, we can instruct webpack to name the file something much friendlier.

      js const HeavyComponent = lazy(() => import(/* webpackChunkName: "HeavyComponent" */ './HeavyComponent');

    1. Similar to prefetching, you can specify the chunk name with an inline comment using the webpackChunkName key

      js const LazyLoad = lazy(() => import(/* webpackChunkName: 'lazyload' */ './LazyLoad') );

    2. For example, if the user is on the login page, you can load the post-login home page. An inline comment with the webpackPrefetch key within the dynamic import function will instruct Webpack to do just this.

      ```js const PrefetchLoad = lazy(() => import( / webpackPrefetch: true / './PrefetchLoad' ) );

      const App = () => { return ( <Suspense fallback="Loading"> {condition && <PrefetchLoad />} </Suspense> ); }; ```

  3. Feb 2023
  4. Dec 2022
  5. Apr 2022
  6. Jan 2022
    1. A note on setting worker-loader’s publicPath with webpack 5

      Webpack 5 introduced a mechanism to detect the publicPath that should be used automatically

      [...]

      Webpack 5 exposes a global variable called __webpack_public_path__ that allows you to do that.

      // Updates the `publicPath` at runtime, overriding whatever was set in the
      // webpack's `output` section.
      __webpack_public_path__ = "/workers/";
      
      const myWorker = new Worker(
        new URL("/workers/worker.js");
      );
      
      // Eventually, restore the `publicPath` to whatever was set in output.
      __webpack_public_path__ = "https://my-static-cdn/";
      
  7. Dec 2021
    1. Web Workers

      As of webpack 5, you can use Web Workers without worker-loader.

      Syntax

      new Worker(new URL('./worker.js', import.meta.url));
      
  8. Nov 2021
    1. [2020] Basics of Module Bundlers for web development

      • Provides a number of uses, most commonly used to compile multiple .js files into a single file for browser to load when users visit a website
      • Terms: Code Splitting, Loaders, Plugins, Dev Server
      • Bundlers: Webpack, Rollup, Parcel, Snowpack
      • Snowpack - only rebuilds files that have changed vs. rebuilding the entire project
  9. Sep 2021
    1. From my point of view, this approach will help you to write cleaner code. Also, it will help to maintain the project. For instance, moving a file from the current directory to another will cause fewer problems, because every file uses an absolute path instead of a relative one. Last but not least, it helps you during development.
    2. alias: { '@': path.resolve(__dirname, 'src'),}
    1. Use this to load modules whose location is specified in the paths section of tsconfig.json when using webpack. This package provides the functionality of the tsconfig-paths package but as a webpack plug-in. Using this plugin means that you should no longer need to add alias entries in your webpack.config.js which correspond to the paths entries in your tsconfig.json. This plugin creates those alias entries for you, so you don't have to!
    1. The declarations you make in the tsconfig.json are re-stated in the webpack.config.js. Who wants to maintain two sets of code where one would do? Not me.
    2. Let's not get over-excited. Actually, we're only part-way there; you can compile this code with the TypeScript compiler.... But is that enough?I bundle my TypeScript with ts-loader and webpack. If I try and use my new exciting import statement above with my build system then disappointment is in my future. webpack will be all like "import whuuuuuuuut?"You see, webpack doesn't know what we told the TypeScript compiler in the tsconfig.json.
    1. config: path.resolve(__dirname, '../config'), vue: 'vue/dist/vue.js', src: path.resolve(__dirname, '../src'), store: path.resolve(__dirname, '../src/store'), assets: path.resolve(__dirname, '../src/assets'), components: path.resolve(__dirname, '../src/components'), '@': path.resolve(__dirname, '../src'),
    2. alias: { _self: path.join(__dirname, 'src/web'), _shared: path.join(__dirname, 'src/shared'), _components: path.join(__dirname, 'src/web/components'), _helpers: path.join(__dirname, 'src/web/helpers'), _layers: path.join(__dirname, 'src/web/layers'), _mutations: path.join(__dirname, 'src/web/mutations'), _routes: path.join(__dirname, 'src/web/routes') }
    3. alias: { '@components': path.join(srcDir, 'components'), '@modules': path.join(srcDir, 'modules'), '@store': path.join(srcDir, 'store') }
    4. Aliases are absolute nonsense for resolving imports. If you don't want to type ../ consider using something like path.resolve(__dirname, '../src') so you can do import Stuff from 'client/components/stuff'; // relative to root of project instead of: import Stuff from 'COMPONENTS/stuff'; // this is dumb
    5. alias: { '@shared': path.dirname(require.resolve('app')), '~': path.join(fs.realpathSync(process.cwd()), 'app'), },
    6. In this example, @shared is the package, ~ is the project. I wouldn't do it this way in the future, but I know this configuration works.
    1. alias: { Library: path.resolve(__dirname, "root/library/"), Single: path.resolve(__dirname, "root/test.js"), },
    2. alias: { Single$: path.resolve(__dirname, "root/test.js"), },
    1. Webpack's resolve.mainFields option determines which fields in package.json are used to resolve identifiers. If you're using Svelte components installed from npm, you should specify this option so that your app can use the original component source code, rather than consuming the already-compiled version (which is less efficient).
    1. Webpack 5 no longer polyfills Node.js core modules automatically which means if you use them in your code running in browsers or alike, you will have to install compatible modules from npm and include them yourself. Here is a list of polyfills webpack has used before webpack 5:
    1. I am not going to do Webpack support. I’ve been pretty lenient in the past and answered most Webpack support questions, but it takes a lot of my time that I could have spent on more important things. I will instead refer users to the Webpack support channels.
    1. Run the Rails server (bin/rails s) and the Webpack Dev Server (bin/webpack-dev-server) via your preferred method. Two terminal tabs will work or create a Procfile and run via overmind or foreman.
  10. May 2021
  11. Mar 2021
    1. Meh... as I said earlier, I think using Webpack is the recommended way now. Another issue is there is no way to generate source maps in production.
    2. But last I have seen comments from DHH, he considered webpack(er) recommended for JS, but Sprockets still the preferred solution for (S)CSS.
    3. I agree about lack of maintenance. It's probably because people use more and more Webpack.
  12. Feb 2021
    1. Ruby on Rails 6 Note:: With the release of Rails 6 there have been some minor changes made to the default configuration for The Asset Pipeline. In specific, by default Sprockets no longer processes JavaScript and instead Webpack is set as the default. The twbs/bootstrap-rubygem is for use with Sprockets not Webpack.
  13. Jan 2021
    1. 6. Add Purgecss for unused CSS removal (optional) Add Purgecss to Sage. Once you’ve successfully added Purgecss, you will need to complete an addition step to make sure Purgecss can extract Tailwind’s classes properly. Luckily, Tailwind has a guide in their docs to add a custom Purgecss extractor.

      Date: 28/01/2021

      Had problem during purgecss installation in my project. Solved using:

      yarn add --dev purgecss-webpack-plugin@0.23.0 glob-all


      More info: Getting an error regarding webpack, during step 1 of adding purgecss ( https://roots.io/guides/removing-unused-css-with-purgecss-uncss-in-sage/ )

      Solved using the command for yarn as given in here:

      https://discourse.roots.io/t/removing-unused-css-with-purgecss-uncss/11586

      That is :

      yarn add --dev purgecss-webpack-plugin@0.23.0 glob-all

    1. If you're using webpack with svelte-loader, make sure that you add "svelte" to resolve.mainFields in your webpack config. This ensures that webpack imports the uncompiled component (src/index.html) rather than the compiled version (index.mjs) — this is more efficient.
  14. Nov 2020
    1. BTW, the modules used to be called moduleDirectories in previous versions.
    2. The resolving process is basically simple and distinguishes between three variants: absolute path: require("/home/me/file") relative path: require("../src/file") or require("./file") module path: require("module/lib/file")

      Very important distinction

    3. In contrast to import (which handles 1+2 pretty much the same way, but would send you looking in node_modules right away) path 'module' indeed means your project root for paths without a need to resolve, like output.path in your webpack config... and: (on resolving) Only 3 is subject to resolve.root and resolve.moduleDirectories resolving, see webpack docs here
    4. The problem is that by default, module paths only work with things imported via npm because the new modules variable on resolve defaults to ["node_modules"]. This lets you import 3rd party code from npm really easily. But it means importing your code with a module path needs a config change.
    1. When enabled, symlinked resources are resolved to their real path, not their symlinked location. Note that this may cause module resolution to fail when using tools that symlink packages (like npm link)
    2. The webpack repository contains an example showing the effect of all devtool variants. Those examples will likely help you to understand the differences.
    1. resolve: { extensions: ['.jsx', '.js'], modules: [ path.resolve(__dirname, 'src'), 'node_modules' ] },
    2. There was a major refactoring in the resolver (https://github.com/webpack/enhanced-resolve). This means the resolving option were changed too. Mostly simplification and changes that make it more unlikely to configure it incorrectly.
    1. The resolve.alias option is used to make sure that only one copy of the Svelte runtime is bundled in the app, even if you are npm linking in dependencies with their own copy of the svelte package. Having multiple copies of the internal scheduler in an app, besides being inefficient, can also cause various problems.
    2. If your Svelte components contain <style> tags, by default the compiler will add JavaScript that injects those styles into the page when the component is rendered. That's not ideal, because it adds weight to your JavaScript, prevents styles from being fetched in parallel with your code, and can even cause CSP violations. A better option is to extract the CSS into a separate file. Using the emitCss option as shown below would cause a virtual CSS file to be emitted for each Svelte component. The resulting file is then imported by the component, thus following the standard Webpack compilation flow.
    3. If you rely on any external dependencies (files required in a preprocessor for example) you might want to watch these files for changes and re-run svelte compile. Webpack allows loader dependencies to trigger a recompile. svelte-loader exposes this API via options.externalDependencies.
    1. Since Sass/libsass does not provide url rewriting, all linked assets must be relative to the output. Add the missing url rewriting using the resolve-url-loader.
  15. Oct 2020
    1. Secondly, whether this works is highly dependent on the module bundler. For example, in codesandbox, when bundling our app with Parcel (or Webpack or Rollup), this solution doesn’t work. However, when running this locally with Node.js and commonJS modules this workaround might work just fine.
    1. Doing so also means adding empty import statements to guarantee correct order of evaluation of modules (in ES modules, evaluation order is determined statically by the order of import declarations, whereas in CommonJS – and environments that simulate CommonJS by shipping a module loader, i.e. Browserify and Webpack – evaluation order is determined at runtime by the order in which require statements are encountered).

      Here: dynamic loading (libraries/functions) meaning: at run time

    1. formvalidation: path.resolve

      Why use resolve.alias to point to 'vendors/formvalidation/dist/es6'? Why not just use an npm package and have package.json name module: 'vendors/formvalidation/dist/es6'

      Then (I think) the examples below like

      import luhn from 'formvalidation/algorithms/luhn';
      

      would work the same but without that workaround.

  16. Sep 2020
    1. If you're using Rollup with rollup-plugin-svelte, this will happen automatically.
    2. If you're using webpack with svelte-loader, make sure that you add "svelte" to resolve.mainFields in your webpack config. This ensures that webpack imports the uncompiled component (src/index.html) rather than the compiled version (index.mjs) — this is more efficient.
    1. Personally for me, this is incredibly hard to read. Regex everywhere, nested objects with different rules and configurations that are very intuitive, multiple loaders that resolve backwards, built in loaders having obscure issues that require using third party loaders in between, separation of plugins and loaders, and so on.
    2. For the past couple of years in particular however, I’ve stopped using Webpack to develop them, opting instead to use Rollup as my primary bundler for apps.
    1. I think your error is because you don't have .mjs in your webpack's resolve.extensions. The file singled out by the error message ./internal is actually a .mjs file, but you only have .svelte extensions...
  17. Jul 2020
  18. Feb 2020
  19. Dec 2019
    1. If none of these commands identified the duplication, try analyzing your bundle for multiple instances of @material-ui/styles. You can just check your bundle source, or use a tool like source-map-explorer or webpack-bundle-analyzer.
    1. This works, but… it's super hacky. I don't really understand the intent of the abstractions in webpack-chain, and looking through the code of existing modules makes me think every module is currently inventing its own hacks to work around some fundamental limitations here.
    1. Webpack supports the ability to run multiple builds by exporting an array of configurations instead of a single configuration.
    2. Various test runners support using compiled webpack code to drive tests, but may be difficult to integrate with webpack, and Neutrino helps alleviate this
    1. To make some of this possible, we had to create our webpack configuration API, called webpack-chain. As you may know, webpack exposes a low-level configuration format, but this format isn't well-suited for merging configuration deterministically across middleware, or even across many projects. With webpack-chain, we expose a chainable or fluent API for aggregating a webpack configuration which is much more deterministic.
  20. Nov 2019
    1. Whereas Webpack bundles all our JavaScript source code files into one bundle (including custom configured build steps), Babel enables us to use recent JavaScript features that are not supported by many browsers yet.
  21. Oct 2019
    1. When you do import '../src/application.css', you're telling webpack include application.css in the build. This does not mean it's going to be compiled into your javascript, only that webpack now knows that you want to compile this file. How that file compilation is handled is depending on how your loaders (css-loader, sass-loader, file-loader, etc.. ) are configured.
  22. Sep 2019
  23. Nov 2018
  24. Oct 2018
  25. Jun 2017
    1. npm install eslint-loader --save-dev

      Note, if you haven't already, you must install eslint,and babel-eslint alongside eslint-loader. Otherwise, you'll get an error from your npm start script.

      npm install eslint babel-eslint eslint-loader

    1. To get it to work, you have to install it first through npm install nodemon --save-dev. After that, you can make it watch webpack config and restart WDS on change. Here's the script if you want to give it a go:

      Force your dev environment to watch updates to your webpack config!

  26. May 2017
    1. npm install --save-dev webpack webpack-dev-server react-hot-loader

      You may run into problems if you don't install webpack-dev-server globally. If you must, as you will have to on many Linux systems, the command is as follows:

      sudo npm install --save-dev webpack-dev-server -g
      
    2. var webpack = require('webpack');

      Note you should also add:

      const path = require('path'); 
      

      See following comments for rationale.

    3. path: 'dist'

      Again, this will throw errors. The solution utilises 'path' (see comment above). The code should look like this in new versions of webpack:

      path: path.resolve(__dirname, 'dist')
      
    4. loader: 'react-hot!babel'

      In newer versions of Webpack, this is disallowed. It should be:

      loader: 'react-hot-loader!babel-loader'
      
  27. Apr 2017
  28. Mar 2017
    1. webpack ./entry.js bundle.js --module-bind 'css=style!css'

      This approach has been deprecated. Here is how it works now:

      webpack ./entry.js bundle.js --module-bind 'css=style-loader!css-loader'

    1. To partition your code into library and application bundles, you will need to create two Webpack configurations, one that creates the library bundle(s) and another that creates the application bundle(s) that use code from the libraries.

      为了分离类库和应用代码,你不得不提供两个配置文件,一个用于类库的bundle;另一个用于应用代码的bundle

  29. Feb 2016
    1. but also it is extremely easy to transition from browserify to webpack when needed.
    2. If however, you’re predominantly dependent on the NPM ecosystem and you want a tool with a small and very well designed API and takes minimal configuration, you should go for Browserify

      We don't particularly need Node compatibility at the moment, but "small and well designed API" is appealing.

      On the other hand, not having to hunt around and collect all the tools together for packaging code for the browser is also appealing.

    1. This is probably the best high level comparison of the approach of Webpack and Browserify that I've seen.

  30. Jan 2016
    1. The greatest advantage Webpack has over these tools is Hot Module Replacement (HMR). In short, it provides a way to patch the browser state without a full refresh. We'll discuss it in more detail when we go through the React setup