78 Matching Annotations
  1. 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.
  2. 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.
    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
  3. 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.
  4. 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.
  5. 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.

  6. 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...
  7. Jul 2020
  8. Feb 2020
  9. 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.
  10. 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.
  11. 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.
  12. Sep 2019
  13. Nov 2018
  14. Oct 2018
  15. 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!

  16. 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'
      
  17. Apr 2017
  18. 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

  19. 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.

  20. 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