`parser.hooks.new` not called for classes within the same file. about webpack

[Danielku15]

Yes, I will try to open a PR soon. Should be there the next few days latest. Locally solution 1 worked fine for me. But have to check all unit tests first.

[alexander-akait]

Feel free to send a PR, we have a lot of tests, so we will catch potential problems

[Danielku15]

I found something suspicious which might allow an easy fix:

1. Various top level symbols are marked by the InnerGraphPlugin:
   

   webpack/lib/optimize/InnerGraphPlugin.js

   Line 133 in 611bded

   const fn = InnerGraph.tagTopLevelSymbol(parser, name);

2. The InnerGraph.tagTopLevelSymbol first defines a variable in the parser with the name and then additionally tags the variable with the top level symbol.
   

   webpack/lib/optimize/InnerGraph.js

   Lines 269 to 279 in 611bded

   	parser.defineVariable(name);
   	const existingTag = /** @type {TopLevelSymbol} */ (
   	parser.getTagData(name, topLevelSymbolTag)
   	);
   	if (existingTag) {
   	return existingTag;
   	}
   	const fn = new TopLevelSymbol(name);
   	parser.tagVariable(name, topLevelSymbolTag, fn);

3. The problem:
   1. parser.defineVariable adds a variable with the current scope as value.
   2. parser.tagVariable also defines a variable but with the correct top level symbol as value. But as there is already a VariableInfo registered from defineVariable resulting in the name not to be set

I see two potential fixes in this code path:

1. In InnerGraph.tagTopLevelSymbol we remove the call to parser.defineVariable. (or move it into the if-statement when a tag already exists).
   • Feels like the safer option as the change is quite isolated and just ensures we do not double-define the variable with missing info.
2. In JavaScriptParser.tagVariable we fill the name we know instead of true into the VariableInfo.
   • It seems the old name was used before and things were refactored as part of ec51894 I'm not so sure about the impact of this change.

[alexander-akait]

Just looked at the reproducible test repo, yeah, we need to fix it, because other plugins can be broken, it can work for the development mode, but broken for the production mode, it is a critical issue... Will you look at this?

[Danielku15]

Made a proposal for fixing the problem. I'm willing to contribute the change as an individual developer but I'm a bit reluctant to provide so many personal details (e.g. mailing address) in the EasyCLA to just contribute some code to this project.

[VivekShahare04]

I wanted to resolve this issue

[VivekShahare04]

see if we directly adjust the hook registration logic to work with identifiers ,
(node:8984) [DEP_WEBPACK_COMPILATION_NORMAL_MODULE_LOADER_HOOK] DeprecationWarning: Compilation.hooks.normalModuleLoader was moved to NormalModule.getCompilationHooks(compilation).loader

it will give you just deprecation warning ,so if incase we adjust it so that we're tapping into the expression hook for the "new" keyword. Then, we check if the argument to new is an identifier (assuming it's a simple class name without further qualification) and directly check if it matches "NotWorkingClass"
This approach circumvents the need for the parser to fill freeName correctly and directly handles the class name. Try this adjustment in your code to see if it resolves the issue with NotWorkingClass expressions not triggering the hook.

I am going to attach my piece of code......

tell me if it helps you if not then we will work on this issue more