diff --git a/lib/dependencies/CommonJsImportsParserPlugin.js b/lib/dependencies/CommonJsImportsParserPlugin.js
--- a/lib/dependencies/CommonJsImportsParserPlugin.js
+++ b/lib/dependencies/CommonJsImportsParserPlugin.js
@@ -282,7 +282,7 @@ class CommonJsImportsParserPlugin {
 				dep.asiSafe = !parser.isAsiPosition(expr.range[0]);
 				dep.optional = !!parser.scope.inTry;
 				dep.loc = expr.loc;
-				parser.state.module.addDependency(dep);
+				parser.state.current.addDependency(dep);
 				return true;
 			}
 		};
@@ -299,7 +299,7 @@ class CommonJsImportsParserPlugin {
 				dep.asiSafe = !parser.isAsiPosition(expr.range[0]);
 				dep.optional = !!parser.scope.inTry;
 				dep.loc = expr.callee.loc;
-				parser.state.module.addDependency(dep);
+				parser.state.current.addDependency(dep);
 				parser.walkExpressions(expr.arguments);
 				return true;
 			}
diff --git a/lib/dependencies/URLPlugin.js b/lib/dependencies/URLPlugin.js
--- a/lib/dependencies/URLPlugin.js
+++ b/lib/dependencies/URLPlugin.js
@@ -82,7 +82,7 @@ class URLPlugin {
 							relative
 						);
 						dep.loc = expr.loc;
-						parser.state.module.addDependency(dep);
+						parser.state.current.addDependency(dep);
 						InnerGraph.onUsage(parser.state, e => (dep.usedByExports = e));
 						return true;
 					});

diff --git a/test/configCases/parsing/issue-14720/index.js b/test/configCases/parsing/issue-14720/index.js
new file mode 100644
--- /dev/null
+++ b/test/configCases/parsing/issue-14720/index.js
@@ -0,0 +1,7 @@
+it("should generate a chunk for a full require dependencies in require.ensure", done => {
+	require.ensure([], () => {
+		expect(require("./module").property).toBe(42);
+		expect(__STATS__.chunks.length).toBe(2);
+		done();
+	});
+});
diff --git a/test/configCases/parsing/issue-14720/module.js b/test/configCases/parsing/issue-14720/module.js
new file mode 100644
--- /dev/null
+++ b/test/configCases/parsing/issue-14720/module.js
@@ -0,0 +1 @@
+exports.property = 42;
diff --git a/test/configCases/parsing/issue-14720/webpack.config.js b/test/configCases/parsing/issue-14720/webpack.config.js
new file mode 100644
--- /dev/null
+++ b/test/configCases/parsing/issue-14720/webpack.config.js
@@ -0,0 +1,4 @@
+/** @type {import("../../../../").Configuration} */
+module.exports = {
+	mode: "production"
+};

Inside require.ensure, using require with chained property causes dependencies to be added to wrong chunk
# Bug report

_EDIT: originally thought this happened with TypeScript dependency but that's not the case, so updating description._

**What is the current behavior?**

When using `require.ensure` along with a specified chunkName to require code where a chained property reference is used (see below), the dependency module will not get added to the specified chunk, but instead to the chunk of the caller.  This massively breaks lazy loading behaviour in our code base.

An example of what is meant by "chained property reference" can be seen here.  Anything where there is a chained reference/call immediately after the require would cause this issue.

    require.ensure([], () => {
        const ModuleB = require("./ModuleB").ModuleB;
    }, "chunk2");

**If the current behavior is a bug, please provide the steps to reproduce.**

Please see the Github repo here for a repro case build with both Webpack 3 (the expected behaviour) and Webpack 5 (the unexpected behaviour): https://github.com/scameron/webpack-issue.

**What is the expected behavior?**

All code for the `require.ensure` should be added to the specified chunk, regardless of its origin.

It is breaking change, please read changelog
> It is breaking change, please read changelog

I've looked in all of the migration docs and changelogs I can find but maybe I'm missing it.  Which log are you referring to?
~~Try this https://webpack.js.org/configuration/module/#moduleparserjavascript~~, oh not, only `webpackIgnore` supported
No solutions, please rewrite your code on ESM
`require.ensure` works fine with JS dependencies.  The issue seems to only happen with TS (or, at least, with non-JS).

`require.ensure` worked with TS in previous releases and that call is not (yet) deprecated so why isn't this a valid bug to fix?
`require.ensure` is frozen due it is non standard, but give me time I will look deeply
It happens not only with TS, using JS webpack still move `ModuleB` in `chunk1`
> It happens not only with TS, using JS webpack still move `ModuleB` in `chunk1`

What do you mean by "using JS" ?   `ModuleC` is JS and it gets moved to `chunk2`.   What's the difference with `ModuleB` if not the fact that it is TS?
If you rename `ModuleB.ts` to `ModuleB.js` problem persists
Oh, if you change:
```
const ModuleB = require("./ModuleB").ModuleB;
ModuleB.testFunction();
```

on:

```
const ModuleB = require("./ModuleB");
ModuleB.testFunction();
```

All works fine.
That actually makes more sense that it is related to the export and not to the language of the originating code.  Good one!

Honestly, though, we have an enormous code base and while we have it in our backlog to move to ESM, anything requiring changing our requires will be an enormous effort and wouldn't be feasible in the short term.

Since this worked in a previous version, would it be possible to investigate this as a bug fix, even though there are workarounds?

The fact that this doesn't fail explicitly, but rather just silently changes the internal loading behaviour, is pretty insidious.  I bet there are a lot of legacy projects around that are affected by this.  You wouldn't believe what this issue did to our runtime code footprint.  We are seeing a huge amount of code eager-loaded where it used to be lazy-loaded on demand.
Yes, there is a problem somewhere, unfortunately, this is not at all a priority for us, and I'm afraid that the fix will not be in the near future, anyway you can investigate it and send a fix, most likely the problem is not so difficult
I think I see the problem. In `CommonJsImportsParserPlugin.js` there are a couple of places where `addDependency` is called on the module instead of the current parser state. Looks like an easy fix so I’ll try to do a PR for that with a test. 
test/ConfigTestCases.basictest.js