Implementing Tree-Shaking for Vue Components

This challenge focuses on understanding and implementing the core concept of tree-shaking within a Vue.js application context. Tree-shaking is a crucial optimization technique that eliminates unused code from your final bundle, leading to faster load times and reduced bandwidth consumption. You will simulate a simplified version of how a build tool might identify and remove unused Vue components from a project.

Problem Description

Your task is to create a TypeScript function that analyzes a simulated Vue project's entry point and a collection of component definitions to determine which components are actually used. Based on this analysis, you should simulate the output of a tree-shaking process by returning a list of the component names that would be included in the final bundle.

Key Requirements:

Analyze Entry Point: The function must take the content of a main Vue entry file (e.g., main.ts or App.vue) as a string. This entry point will contain imports and usage of other Vue components.
Component Definitions: The function will also receive an array of objects, where each object represents a Vue component definition. Each component object should have at least a name property (string) and potentially a template or setup function property that might contain further component usage.
Identify Direct Usage: Identify components directly imported and used within the entry point's template or script.
Identify Indirect Usage (Recursive): If a component is used, recursively analyze its template and script for usage of other components.
Simulate Bundle: Return an array of strings, where each string is the name of a component that is determined to be "used" (i.e., would not be shaken out).

Expected Behavior:

The function should simulate a static analysis of the provided code. It doesn't need to execute the JavaScript or Vue code. It should look for patterns like:

import ComponentName from './ComponentName.vue';
<ComponentName /> (in templates)
const components = { ComponentName }; (in script options API)
import { ComponentName } from '...' and then h(ComponentName, ...) (in render functions)
import { defineComponent } from 'vue'; defineComponent({ components: { ComponentName } }) (in script setup)

Edge Cases to Consider:

Components imported but not used.
Components used indirectly through other used components.
Circular dependencies (though for simplicity, you might assume no infinite loops in usage).
Dynamic imports (for this challenge, we'll assume static imports).
Aliases for imported components (e.g., import MyComp as ComponentName from ...). We can simplify this by assuming direct naming.

Examples

Example 1:

// Simulated Entry Point Content
const entryPointContent = `
import { createApp } from 'vue';
import App from './App.vue';
import HelloWorld from './components/HelloWorld.vue';
import MyButton from './components/MyButton.vue';

const app = createApp(App);
app.component('HelloWorld', HelloWorld); // Global registration
app.mount('#app');
`;

// Simulated Component Definitions
const componentDefinitions = [
  { name: 'App', template: '<HelloWorld msg="Welcome to Your Vue.js App"/><MyButton />' },
  { name: 'HelloWorld', template: '<div>{{ msg }}</div>' },
  { name: 'MyButton', template: '<button>Click Me</button>' },
  { name: 'UnusedComponent', template: '<p>I am not used</p>' }
];

// Expected Output
// ['App', 'HelloWorld', 'MyButton']

// Explanation:
// - 'App' is the root component and is used in the entry point.
// - 'HelloWorld' is imported and globally registered, and used within 'App'.
// - 'MyButton' is imported and used within 'App'.
// - 'UnusedComponent' is neither imported nor used.

Example 2:

// Simulated Entry Point Content
const entryPointContent = `
import { defineComponent } from 'vue';
import Layout from './components/Layout.vue';

export default defineComponent({
  components: {
    Layout
  },
  template: '<Layout><p>Content</p></Layout>'
});
`;

// Simulated Component Definitions
const componentDefinitions = [
  { name: 'Layout', template: '<div><slot></slot></div>' },
  { name: 'Sidebar', template: '<div>Sidebar</div>' },
  { name: 'Content', template: '<p>Some Content</p>' }
];

// Expected Output
// ['Layout']

// Explanation:
// - 'Layout' is imported and used in the entry point's template.
// - 'Sidebar' and 'Content' are defined but never imported or referenced anywhere.

Example 3: (Indirect Usage)

// Simulated Entry Point Content
const entryPointContent = `
import { createApp } from 'vue';
import MainLayout from './components/MainLayout.vue';

createApp(MainLayout).mount('#app');
`;

// Simulated Component Definitions
const componentDefinitions = [
  { name: 'MainLayout', template: '<div><Header/><MainContent/><Footer/></div>' },
  { name: 'Header', template: '<h1>My App</h1>' },
  { name: 'MainContent', template: '<p>Welcome!</p>' },
  { name: 'Footer', template: '<p>&copy; 2023</p>' },
  { name: 'SideNav', template: '<ul><li>Nav</li></ul>' }
];

// Expected Output
// ['MainLayout', 'Header', 'MainContent', 'Footer']

// Explanation:
// - 'MainLayout' is used in the entry point.
// - 'Header', 'MainContent', and 'Footer' are used within 'MainLayout's template.
// - 'SideNav' is defined but not used by any component that is ultimately used.

Constraints

The input entryPointContent will be a string representing valid JavaScript/TypeScript syntax, potentially including Vue template syntax within strings.
The componentDefinitions array will contain objects with a name (string) and template (string) property. You can assume component names are unique.
The analysis should be static; no actual code execution is required.
Assume standard Vue component naming conventions (e.g., PascalCase).
Focus on identifying components used directly via imports, global registration (as a simplified string search for app.component(...)), or within other component templates.
Performance is not a primary concern for this challenge, but the solution should be reasonably efficient for a moderate number of components and lines of code.

Notes

You'll likely need to use regular expressions or simple string parsing to identify import statements and component tags.
Consider how to handle component names that might appear as strings (e.g., in object literals for components).
A recursive approach or a worklist algorithm would be suitable for handling indirect dependencies.
The goal is to simulate tree-shaking, not to build a full-fledged build tool parser. Focus on the core logic of identifying used components.
Think about how to efficiently look up component definitions by name.