Requesting Expertise on Idea - NormalModulePrependPlugin #15067
Handfish
started this conversation in
Show and tell
Replies: 1 comment
-
We have Let's use discussions for questions |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Feature request
What is motivation or use case for adding/changing the behavior?
I stumbled upon an interesting technical problem the other day and I think a custom webpack plugin is the solution. I'm going to try my best to explain my problem and thoughts so bare with me.
I've recently decided I want to fork an active-life Typescript / React project and make significant changes / build a library / framework on top of the original source. I intend to keep this project in a different repository since it's purpose divulges from the original repository's intentions. My main concern tackling building a fork like this is to make pulling upstream changes as easy as possible.
I watched this video presentation given posted by the team behind Git Swarm about extending Third Open Source Projects. https://www.perforce.com/webinars/extending-open-source-projects
They took git lab, forked it and extended it in a manner I'd like to emulate. They communicate their goal is to touch as few files in original source as possible to make merges as painless as can be. In their presentation they talk about Ruby Modules and their use of "Prepend", which allows them to Extend the modules in-place and have their newly extended modules swap into the original's place in the project.
Presently, I'm unsure if there is a comparable way to do what they've done utilizing just the features of Typescript. Not being a Typescript expert, I can't say for certain. I do believe though that building an extension for Webpack may allow me to have the most pain-free development experience when developing a modified fork of an active-life product.
Here is the pattern I have in mind:
First I want to create a subdirectory (you can call it extended_app) in the main repo's src directory. In that subdirectory, I will create the exact folder / file structure of the src directory. The files of the subdirectory will import / export all of their respective src directory exports - think of it as an acting HEAD in my filesystem. If I need to override something, I can do it in the subdirectory without touching the original source.
How should this be implemented in your opinion?
What is the expected behavior?
I'd like to take the NormalModuleReplacementPlugin and configure it so that it remaps the src directory to my subdirectory. The problem with the current NormalModuleReplacementPlugin is that it applies to the entire project. I'd like it to remap all occurrences of an import to my subdirectory UNLESS the file it is passing over is within my subdirectory - then I would like to reference its original module location.
The concept I have is as follows:
Let's say the repo I'm extending consists of two files:
I don't want to touch the original files and create merge conflicts so I've created a subdirectory in the main repository. It mirrors the exactly layout of the original application but I want to do some overrides.
Are you willing to work on this yourself?
yes
Presently with NormalModuleReplacementPlugin I can make src/foo reference src/extended_app/foo but the problem is /src/extended_app/foo references itself and creates an infinite loop (circular dependency).
I'm not sure what needs to be done with the plugin - I'm not very keen on the internals of webpack - but I created a demo repo of the problem. It is located here:
https://github.com/Handfish/normal-module-replacement-problem-demo/
I am able to log information at the beforeResolve hook when it passes over my subdirectory files.
Is there an easier pattern to do this without building a Webpack plugin?
Do you think what I'm trying to do is possible? If so - am I on the right track?
Beta Was this translation helpful? Give feedback.
All reactions