[PWA-Kit Extensibility] Implement wild-card module resolution logic @W-15932154

[bendvc]

Description

The PWA-Kit platform uses babel-node to run our PWA-Kit applications (think, typescript-minimal and retail-react-app). Because of this, we have 2 distinct places in our code where it's required that we modify the module resolution algorithm to support extensibility overrides. The first place is via a webpack plugin and the other is the babel-node plugin.

The logic used by these plugins is for the most part the same, so it's important that we don't repeat ourselves and pull that logic out into a set of reusable utilities.

So, in this PR we create those utilities to be used by a webpack and a babel plugin in order to implement wildcard import statement syntax. What this syntax allows us to do is, import a module from a known list of packages where the modules being imported is known to exist in at least one of the packages.

This is the basis of "multi-extensibility" and those "known list" of packages are in fact the list of extensions.

Types of Changes

• [ ] Bug fix (non-breaking change that fixes an issue)
• [x] New feature (non-breaking change that adds functionality)
• [ ] Documentation update
• [ ] Breaking change (could cause existing functionality to not work as expected)
• [ ] Other changes (non-breaking changes that does not fit any of the above)

Breaking changes include:

• Removing a public function or component or prop
• Adding a required argument to a function
• Changing the data type of a function parameter or return value
• Adding a new peer dependency to package.json

Changes

• Create utils for building resolves "packageIterator" array

How to Test-Drive This PR

• Run tests, test should pass.

• Alternately I've deployed a version of the typescript-minimal application that implemented a webpack plugin that uses the core logic in this pr. You can see it here, you can view pages that have been added via extensions here, here and here.

• If you are interested in seeing how the core logic will be used you can take a look at the following branch comparison here

Checklists

General

• [ ] Changes are covered by test cases
• [ ] CHANGELOG.md updated with a short description of changes (not required for documentation updates)

Accessibility Compliance

You must check off all items in one of the follow two lists:

• [ ] There are no changes to UI

or...

• [ ] Changes were tested with a Screen Reader (iOS VoiceOver or Android Talkback) and had no issues
• [ ] Changes comply with WCAG 2.0 guidelines levels A and AA
• [ ] Changes to common UI patterns and interactions comply with WAI-ARIA best practices

Localization

• [ ] Changes include a UI text update in the Retail React App (which requires translation)

[bendvc]

shall we create a feature branch for multi extensibility? this PR doesn't provide much value until we have the webpack/babel plugins

I was hoping someone was going to ask me about this so we can open up a dialog on what we want to do. I'm thinking this is the perfect time to create an next branch. This pr would merge into that branch which represents the next major version of the sdk pacakges in this lib.

Thoughts?

[kevinxh]

shall we create a feature branch for multi extensibility? this PR doesn't provide much value until we have the webpack/babel plugins

I was hoping someone was going to ask me about this so we can open up a dialog on what we want to do. I'm thinking this is the perfect time to create an next branch. This pr would merge into that branch which represents the next major version of the sdk pacakges in this lib.

Thoughts?

I think we could either do what you said, starting the next major version. Or try to ship this as a non-breaking minor version. I also am not sure how much effort would it take to make it a non-breaking change? 🤔

[bendvc]

shall we create a feature branch for multi extensibility? this PR doesn't provide much value until we have the webpack/babel plugins

I was hoping someone was going to ask me about this so we can open up a dialog on what we want to do. I'm thinking this is the perfect time to create an next branch. This pr would merge into that branch which represents the next major version of the sdk pacakges in this lib. Thoughts?

I think we could either do what you said, starting the next major version. Or try to ship this as a non-breaking minor version. I also am not sure how much effort would it take to make it a non-breaking change? 🤔

This is going to be a breaking change solely based on how we are configuring extensibility.. I suppose we can support both ways.. but I don't care for the additional complexity.

For now I've created a feature branch that has the SDKs bumped to 4.0.0-dev. Once we have the "next" branch created, I can rebase this PR to merge into "next"