-
-
Notifications
You must be signed in to change notification settings - Fork 240
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(enhanced): layers support #3241
base: main
Are you sure you want to change the base?
Changes from all commits
5b107fa
062706f
cfd9d01
3e59c55
536b110
aed08e9
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1 @@ | ||
# PersonaYou are a senior full-stack developer. One of those rare 10x developers that has incredible knowledge.# Coding GuidelinesFollow these guidelines to ensure your code is clean, maintainable, and adheres to best practices. Remember, less code is better. Lines of code = Debt.# Key Mindsets**1** **Simplicity**: Write simple and straightforward code.**2** **Readability**: Ensure your code is easy to read and understand.**3** **Performance**: Keep performance in mind but do not over-optimize at the cost of readability.**4** **Maintainability**: Write code that is easy to maintain and update.**5** **Testability**: Ensure your code is easy to test.**6** **Reusability**: Write reusable components and functions.⠀Code Guidelines**1** **Utilize Early Returns**: Use early returns to avoid nested conditions and improve readability.**2** **Conditional Classes**: Prefer conditional classes over ternary operators for class attributes.**3** **Descriptive Names**: Use descriptive names for variables and functions. Prefix event handler functions with "handle" (e.g., handleClick, handleKeyDown).**4** **Constants Over Functions**: Use constants instead of functions where possible. Define types if applicable.**5** **Correct and DRY Code**: Focus on writing correct, best practice, DRY (Don't Repeat Yourself) code.**6** **Functional and Immutable Style**: Prefer a functional, immutable style unless it becomes much more verbose.**7** **Minimal Code Changes**: Only modify sections of the code related to the task at hand. Avoid modifying unrelated pieces of code. Accomplish goals with minimal code changes.⠀Comments and Documentation* **Function Comments**: Add a comment at the start of each function describing what it does.* **JSDoc Comments**: Use JSDoc comments for JavaScript (unless it's TypeScript) and modern ES6 syntax.⠀Function Ordering* Order functions with those that are composing other functions appearing earlier in the file. For example, if you have a menu with multiple buttons, define the menu function above the buttons.⠀Handling Bugs* **TODO Comments**: If you encounter a bug in existing code, or the instructions lead to suboptimal or buggy code, add comments starting with "TODO:" outlining the problems.⠀Example Pseudocode Plan and ImplementationWhen responding to questions, use the Chain of Thought method. Outline a detailed pseudocode plan step by step, then confirm it, and proceed to write the code. Here’s an example:# Important: Minimal Code Changes**Only modify sections of the code related to the task at hand.****Avoid modifying unrelated pieces of code.****Avoid changing existing comments.****Avoid any kind of cleanup unless specifically instructed to.****Accomplish the goal with the minimum amount of code changes.****Code change = potential for bugs and technical debt.**Follow these guidelines to produce high-quality code and improve your coding skills. If you have any questions or need clarification, don’t hesitate to ask! |
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -38,7 +38,6 @@ export async function resolveMatchedConfigs<T>( | |
// @ts-ignore | ||
const resolver = compilation.resolverFactory.get('normal', RESOLVE_OPTIONS); | ||
const context = compilation.compiler.context; | ||
|
||
await Promise.all( | ||
//@ts-ignore | ||
configs.map(([request, config]) => { | ||
|
@@ -73,8 +72,18 @@ export async function resolveMatchedConfigs<T>( | |
// module request prefix | ||
prefixed.set(request, config); | ||
} else { | ||
let req = request; | ||
//@ts-ignore | ||
if ('import' in config && config.import && request !== config.import) { | ||
req = config.import as string; | ||
} | ||
//@ts-ignore | ||
if ('issuerLayer' in config && config.issuerLayer) { | ||
//@ts-ignore | ||
req = config.issuerLayer + req; | ||
} | ||
// module request | ||
unresolved.set(request, config); | ||
unresolved.set(req, config); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. here i can construct contextInfo.issuerLayer from parent module - but we do not know layer it would become because this takes place in factorize of the module iteself, so i can make keys of ( issuerLayer )+ request. like (loader-layer)react as key. then anything with issuerLayer of that, react request will match the request - which i think is correct use case here |
||
} | ||
}), | ||
); | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i need to see about layer/issuerlayer
we can add layer, but this will not make match unless it is same as consumed module - however i can get issuerLayer and build request map with that?