Fix: using pnpm from corepack when install dependency

[OrkWard]

This PR proposes multiple improvements to the usage of package manager.

1. corepack is bundled within node since 14.19.0, meaning that there is no need to manually install it using npm install -g corepack;
2. Since package.json has declare packageManager here, it is supposed all dependencie should be managed by the specified manager version. Avoid install pnpm manually in ci, just run corepack enable. Meanwhile, using two package manager with different resolve algorithm will never be a good idea, for which yarn.lock is removed;
3. Some background first: corepack works by intercepting pnpm, yarn executable in the path, and automatically install the version mensioned in packageManager. These installation may also need a proxy or mirrors of npm registry in a limited network environment. I guess author of this PR exprience such cases(as he added proxy config for apt-get as well), and mistakely think it's caused by pnpm.
4. https://registry.npmjs.org/ is the offical registry, targetting it don't change anything. I change the registry to npmmirror maintaing by Alibaba(there is a benchmark in 2023).

I delete the commented proxy config as well, for users can add their own as needed

Remaining Work: Execution of pip and pnpm using a mirror, but apt-get don't. I wonder in which environment does this Dockfile supposed to be build, or people just adjust it themselves?

---

Updated 2025.1.3: rebase upon master; add mirror config for apt-get

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
running-page	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Jan 3, 2025 11:38am

[yihong0618]

@OrkWard Hi Thank you very much, I merged #761 first can you help to fix the conflicts?

[OrkWard]

Updated, see above

[yihong0618]

Updated, see above

do we need to delete the lock file?

[OrkWard]

do we need to delete the lock file?

Which lock file do you refer to?

To provide more context for why I delete the yarn.lock, just pick a random dependency, say @mapbox/polyline, is resolved to 1.2.1 in yarn.lock and 1.2.0 in pnpm-lock, which probably won't introduce any trouble at present, but is unpredictable in the future as two lock files diverge more and more.

If you refering to the remaining pnpm-lock, it's the core of version management in nodejs environment and should always be included.