该项目从 https://gitlab.com/gitlab-org/gitlab.git 镜像。
拉取镜像更新于 。
- 9月 12, 2022
-
-
由 Paul Slaughter 创作于
- Previously we were regexing the source code - Now we can actually run this module and retrieve from it's export
-
- 2月 28, 2022
-
-
由 Lukas Eipert 创作于
If `live_reload` is disabled, we accidentally kill the webpack dev server because `devServer.webSocketServer.clients` is undefined, because we are checking the wrong condition. This fixes the condition check.
-
- 2月 09, 2022
-
-
由 Lukas Eipert 创作于
This fixes a bunch of dependency audit problems. Luckily the new webpack-dev-server is compatible with webpack v4 and webpack v5. Updating this separately from the rest of webpack seems like a step in the right direction. So far there are no problems with the webpack dev server locally and HMR and all these things seem to work perfectly.
-
- 1月 20, 2022
-
-
由 Lukas 'Eipi' Eipert 创作于
Webpack internally defaults to md4 hashing because it is fast. Similarly some loaders (e.g. cache-loader) use md5. This is generally no problem because they are mainly used for file hashes and nothing cryptography related. Unfortunately FIPS enabled versions of node do not allow to use these hasing algorithms because they are considered broken by cryptographic standards. All of these cryptographic functions come from openssl. So if one uses md4 or md5 on a FIPS enabled system, the webpack process will error. Luckily we can just monkey-patch the createHash function in node in order to use another algorithm. Thanks to this comment: https://github.com/webpack/webpack/issues/13572#issuecomment-923736472 See also: https://gitlab.com/gitlab-org/gitlab/-/issues/322883 Changelog: changed
-
- 8月 27, 2021
-
-
由 Mark Florian 创作于
-
- 8月 26, 2021
-
-
由 Mark Florian 创作于
This adds least-recently-used-cache-like behaviour to the incremental webpack compiler. The `DEV_SERVER_INCREMENTAL_TTL` environment variable now determines the number of days that page bundles are considered "recent", and should be eagerly compiled. This number represents the trade-off between lazy/eager compilation versus low/high memory consumption of the webpack development server. A higher number means fewer pages needing to be compiled on demand, at the cost of higher memory consumption. A lower number means lower memory consumption, at the cost of more pages being compiled on demand. A value of `0` means that all pages in your history, regardless of how long ago you visited them, are eagerly compiled. This also makes the compiler record a history of visited pages even when disabled, so that if and when it _is_ enabled, that history can still be used to inform the LRU cache. The history-recording function is explicitly disabled in the case that webpack is running in CI. Part of https://gitlab.com/gitlab-org/gitlab/-/issues/300412.
-
- 7月 23, 2021
-
-
由 JeremyWuuuuu 创作于
- Add condition for `EE_ONLY` to make the judgment aligned with gitlab.rb
-
- 7月 22, 2021
-
-
由 Jeremy Wu 创作于
-
- 5月 14, 2021
-
-
由 Mark Florian 创作于
-
- 3月 25, 2021
-
-
由 Paul Slaughter 创作于
- A missing gitlab_schema.graphql file can cause unrelated and hard to debug issues. - This can be overwritten with GL_IGNORE_WARNINGS=1
-
- 3月 10, 2021
-
-
This re-adds our config/, scripts/ and *.config.js files to eslint, together with some rules to make it a little easier for those node-scripts, e.g. console logging or importing node or dev dependencies should be fine.
-
- 2月 01, 2021
-
-
由 Paul Slaughter 创作于
Extends is used to represent an "is-a" relationship. It doesn't make sense for IncrementalWebpackCompiler is a NoopCompiler. Just because they are the same interface does not mean they have to inherit eachother.
-
- 1月 29, 2021
-
-
由 Paul Slaughter 创作于
-
由 Albert Salim 创作于
-
由 Lukas 'Eipi' Eipert 创作于
In order to have quicker compilations while developing we are adding an incremental compiler to webpack to render routes on demand. When the developer is working on the dev server and enables the incremental compiler with DEV_SERVER_INCREMENTAL=true, the new functionality is enabled. The biggest problem to solve here: How can we _know_ which entry point to render and which not? Our current webpack integration with rails requires the webpack manifest to have a list of all existing entry points. So our incremental compiler takes the following approach: Every compilation of webpack will run `generateEntries` which generates a list of all our entry points. In that function we are able to replace all page specific entrypoints and point them to an empty file, unless we explicitly want them to compile. In the webpack-dev-server itself we register a middleware which keeps track of all the page specific bundles requested. Whenever a page specific bundle is requested that hasn't been requested before, we add it to the list of bundles we want compiled. This approach allows us to dynamically change the entry points without a need to restart webpack alltogether _and_ it works with hot module reloading. Rather than pointing to a blank javascript we are pointing to one which renders an overlay to let the user know that webpack compiles the page for the first time. Additionally we keep a history of requested routes in `tmp/cache` in order to keep the list of compiled entry points between sessions. In a next iteration we can add a bit of logic and e.g. remove entry points the developer hasn't been visiting in a week. First results are really promising (on my machine): - Memory consumption when idling: 1600MB => 340MB - Max memory: ~2200MB => ~1000MB - Initial Compilation time: 58s => 15s - Recompile afer a file change: 13s => 3s - Visiting a new page that hasn't been visited before, it takes about four seconds to reload the page, seven seconds to completely load the page. Currently the technique still watches all of the source files, so changing an unrelated file will trigger a recompilation. This is however a minor caveat and the same behavior that we currently have, maybe we can optimize in the future.
-
- 12月 24, 2020
-
-
由 Lukas Eipert 创作于
Part of our prettier migration; changing the arrow-parens style.
-
- 12月 23, 2020
-
-
由 Lukas Eipert 创作于
Mandatory not to break master. Automatically created with prettier.
-
- 8月 24, 2020
-
-
由 Vitaly Slobodin 创作于
-
- 5月 15, 2020
-
-
由 Paul Slaughter 创作于
**What happened?** Previously we just checked the immediate parent to see if the module was being included from eslint. Now we recursively check all the parents. Also moves this eslint check to it's own config/helper
-
- 12月 17, 2019
-
-
由 Mike Greiling 创作于
Introduces the ability to enable webpack DLL support by passing the flag WEBPACK_VENDOR_DLL=true while running webpack or webpack-dev-server.
-
- 10月 22, 2019
-
-
由 allison.browne 创作于
-
- 10月 16, 2019
-
-
由 Kamil Trzciński 创作于
This removes the usage of IS_GITLAB_EE and prefer to use FOSS_ONLY that has the following states: 1. nil/empty string: use CE or EE depending on sources 1. false: use CE or EE depending on sources 2. true: use CE always
-
- 10月 15, 2019
-
-
由 Kamil Trzciński 创作于
Currently: 1. If `IS_GITLAB_EE=` is used, it fails to generate Webpack as it cannot be parsed as JSON, 2. If `IS_GITLAB_EE=1` is used, it fails on GitLab CE, 3. If `IS_GITLAB_EE=0` it does work correctly, and disables EE, 4. If `IS_GITLAB_EE=1` is used on GitLab EE it effectively required to run on EE changes. This changes to: Make `IS_GITLAB_EE=` to donate the intent to disable or enable EE sources, instead of requiring it, and makes the check consitent in behaviour.
-
- 4月 05, 2019
-
-
由 Winnie Hellmann 创作于
(cherry picked from commit 64e9cf00)
-
由 Winnie Hellmann 创作于
-
- 3月 29, 2019
-
-
由 Winnie Hellmann 创作于
(cherry picked from commit baa671a3)
-
由 Winnie Hellmann 创作于
-