- Previously we were regexing the source code
- Now we can actually run this module and retrieve from it's export

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.

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.

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

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.

- Add condition for `EE_ONLY` to make the judgment aligned with gitlab.rb

- A missing gitlab_schema.graphql file can cause
  unrelated and hard to debug issues.
- This can be overwritten with GL_IGNORE_WARNINGS=1

Lukas 'Eipi' Eipert 创作于 4 years ago ，Vitaly Slobodin 提交于 4 years ago

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.

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.

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.

Part of our prettier migration; changing the arrow-parens style.

Mandatory not to break master. Automatically created with prettier.

**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

Introduces the ability to enable webpack DLL support by passing
the flag WEBPACK_VENDOR_DLL=true while running webpack or
webpack-dev-server.

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

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.

(cherry picked from commit 64e9cf00)

(cherry picked from commit baa671a3)