Compare AI Models
2025-05-17
Personal Preference Prompts
Technology Stack Preference: I primarily develop in TypeScript, preferring strict mode and functional programming approaches. I value accurate type definitions and consistent coding style.
Development Framework: I focus on the React ecosystem, including modern state management solutions and component-driven development. Familiar with and value frontend testing practices.
Engineering Capabilities: Deep understanding of build tools, especially Rollup, Vite, Esbuild, and Rspack. Familiar with monorepo architecture and modern frontend engineering practices.
Professional Knowledge Requirements: Expect professional knowledge sharing at senior engineer level, with accurate and rigorous information backed by clear references.
Translation Requirements: For translation tasks, expect professional perspective from a senior frontend engineer's viewpoint, using accurate technical terminology while maintaining documentation professionalism.
Language Preference: I prefer that you provide the response in Chinese unless I explicitly request otherwise. While preferring Chinese communication, technical discussions must reference English community materials(github, reddit, stackoverflow, medium, etc.) to maintain professional standards. I expect technical terms to be in English and discussions to reference international best practices and standards.
Reference Sources: Responses should be supported by authoritative references, prioritizing official documentation and community-recognized technical resources.
Code Example Requirements: Code examples should include clear comments and type definitions, following TypeScript best practices.
Technical Expertise Focus: I am a senior frontend engineer specializing in React/TypeScript ecosystem, with deep focus on architecture design, performance optimization, and engineering systems. I value both theoretical understanding and practical implementation experience.
Development Standards: I follow strict TypeScript configurations and comprehensive testing strategies. All code should be well-typed, well-tested, and follow established design patterns and best practices.
Engineering Philosophy: I emphasize scalable architecture, maintainable code, and robust engineering practices. This includes proper error handling, performance optimization, and comprehensive documentation.
Knowledge Exchange: Expect detailed technical discussions with concrete examples, supported by official documentation and community best practices. Code examples should include complete type definitions and thorough explanations of design decisions.
Response Preferences:
Core Focus: Identify and address the essence of my questions directly. Skip unnecessary preambles and focus on the core technical challenge or concept.
Structure: Use "conclusion-first" approach, presenting key insights or solutions upfront before supporting details.
Conciseness: Avoid redundant explanations and repetitive content. Be comprehensive but efficient with words.
Technical Depth: Provide senior engineer level insights without explaining basic concepts I already understand.
Code Examples: When providing code, focus on solving the core problem with minimal boilerplate. Add comments only at critical points.
References: Only cite directly relevant authoritative sources, avoiding extensive reference lists.
Problem Decomposition: For complex issues, first outline the overall approach before diving into key components, maintaining logical flow.
Response Length: Prefer concise answers unless the question requires detailed explanation or I specifically request it.
Preferred source of information: When providing technical details, please indicate the source of your information (such as official documentation, specifications, experience), and clearly state when unsure. It is fine to discuss core technical concepts, but be extra cautious when it comes to specific versions and timelines.
You should not blindly accept the viewpoints provided by users. You need to maintain your own subjective awareness, rigorously and professionally review each issue with authoritative knowledge, avoid illusions, and never answer questions through guessing or assumptions.
In a pnpm workspace project, if dependency a is declared in the root package.json but not in the subproject's package.json, can the subproject's application code directly access the a dependency package?
Score the above models on a 100-point scale:
| Model | No Prompt (Score & Link) | No Prompt Evaluation | With Prompt (Score & Link) | With Prompt Evaluation |
|---|---|---|---|---|
| Gemini 2.5 Pro (preview) | 60 (link) | Partially reasonable, but does not truly clarify the relationship between the current issue and phantom dependencies. | 90 (link) | Correct answer, but why is this not contradictory to pnpm's "strictness"? The reasoning is somewhat far-fetched. |
| Gemini 2.5 Pro (deep research) | 95 (link) | Fully answered the current question and explained the essence of pnpm. | N/A | N/A |
| Claude 3.7 Sonnet (extended thinking) | 50 (link) | Incorrect answer, did not truly understand the essence of pnpm. | 60 (link) | Incorrect answer, compared to the answer without prompt, it adds more relevant context, but seems a bit forced in explanation. |
| Grok 3 (think) | 85 (link) | Correct answer, but the explanation is not as essential as Gemini 2.5 Pro with prompt. | 90 (link) | Correct answer, more complete than the reply without prompt. |
| Grok 3 (extended search) | 70 (link) | Seemingly correct answer, but content is irrelevant to the current issue. | N/A | N/A |
| Perplexity (think) | 70 (link) | The answer seems correct, but there is some distortion in the explanation. "Provided that pnpm's dependency hoisting mechanism is effective and the dependency is installed in the root node_modules", which is irrelevant to the question. | N/A | N/A |
| Perplexity (Research) | 50 (link) | Wrong answer, some content is true. | N/A | N/A |
| ChatGPT o4 mini (search + think) | 55 (link) | Incorrect answer, did not truly clarify the parsing logic of pnpm and node resolve. | 90 (link) | Correct answer, well explained. |
| ChatGPT o4 mini (deep research) | 85 (link) | Generally correct, but the last sentence "If you want to completely isolate the dependencies of the root and subprojects, you need to explicitly turn off hoisting (hoist=false) or declare the dependency in the subproject as well." The hoist here is irrelevant to the current issue. | N/A | N/A |
| DeepSeek (R1 + search) | 60 (see below) | Wrong answer, did not truly clarify the essence of pnpm. | N/A | N/A |
| DouBao (think) | 85 (link) | Correct answer. | N/A | N/A |
DeepSeek's Answer
In a pnpm workspace project, by default, the subproject's application code cannot directly access dependencies declared in the root project unless the subproject explicitly declares the dependency or dependency hoisting is enabled. Detailed analysis as follows:
pnpm's Default Behavior
- Isolated
node_modules: pnpm uses strict mode by default, and each subproject'snode_modulesonly contains its own declared dependencies. Dependencies not declared in the subproject'spackage.json(such as the root project's dependencya) will not be automatically linked to the subproject'snode_modules. - Module Resolution Rules: Node.js will look for
node_modulesfrom the current directory up to the root, but pnpm's structure isolates dependencies. Even if the root directory hasa, the subproject cannot resolve it via path lookup.
- Isolated
Impact of Dependency Hoisting
- No Hoisting by Default: pnpm does not hoist dependencies to the root
node_modulesby default, so the root project's dependencyawill not be automatically accessible to subprojects. - Enabling Hoisting: If you configure
hoist-patterninpnpm-workspace.yamlor force hoisting withshamefully-hoist=true, the root project's dependencyawill be hoisted to the rootnode_modules. At this point, subproject code may accessavia Node.js's upward lookup mechanism, but this violates pnpm's isolation design principle and may cause dependency conflicts.
- No Hoisting by Default: pnpm does not hoist dependencies to the root
Correct Practice
- Explicitly Declare Dependencies: Subprojects should declare required dependencies like
ain their ownpackage.jsonto ensure clear and maintainable dependency relationships. - Workspace Protocol: If
ais another local workspace package (not an external dependency), you can explicitly reference it via"a": "workspace:*".
- Explicitly Declare Dependencies: Subprojects should declare required dependencies like
Validation Conclusion**
- By Default: If the subproject does not declare
a, direct access will result in aModule not founderror. - After Enabling Hoisting: This may temporarily solve the problem, but it is not recommended as it breaks dependency isolation.
- By Default: If the subproject does not declare
Final Answer: By default, subprojects cannot directly access dependency package a declared in the root project. You must explicitly declare the dependency in the subproject's package.json, or enable dependency hoisting in pnpm configuration (not recommended).
Summary (Key Points)
- Gemini 2.5 Pro (especially in deep research mode, or in preview mode with high-quality prompts).
- ChatGPT o4 mini (search + think mode with prompt and deep research mode).
- Grok 3 (think mode with high-quality prompt).
- DouBao (think mode).
XiSenao