pattern-lab / patternlab-node

The Node version of Pattern Lab
http://patternlab.io
MIT License
2.05k stars 405 forks source link

Deprecate `checkAndInstallPackage` and `fetchPackage` #1247

Closed ringods closed 3 years ago

ringods commented 4 years ago

I'm hearing from the core maintainers that everything in Patternlab should be(come) more explicit. In the uikit handling (#1225, #1246), I'm making the package name and explicit requirement and I'm loading resources via de NodeJS resolver.

NPM, Yarn v1, Yarn v2 and pnpm don't all have the same "package" lookup strategy. Yarn v2 with PnP even wants to get rid of the complete node_modules folder(s). The reason to work via the NodeJS resolver is that it doesn't matter anymore which package manager our users are using.

As part of the above work, I also bumped into an issue with starterkits. The CLI has the option to install a starterkit based on the package name. But if it isn't found, there is a check to detect which package manager is used and a subprocess will install the required package. But installing the package in a subprocess will, given the different package managers, not always make the package available in the parent process.

So, a starterkit should be a dependency of the project at hand if the lookup happens via the resolver. That is why I want to get rid of the functions checkAndInstallPackage and fetchPackage:

https://github.com/pattern-lab/patternlab-node/blob/f4d6bd1fd2afd3cb4403350f24d747e44c54cd6c/packages/cli/bin/utils.js#L125-L166

@sghoweri @JosefBredereck

ringods commented 4 years ago

@JosefBredereck @mfranzke @sghoweri due to the resolver changes I'm slowly integrating, bugs are reported (#1257) which expose exactly the scenario as described in this issue: npm create pattern-lab installs packages in the project folder from a child node process and immediately afterwards tries to resolve these from the parent node process.

This fails because the resolver loads from a temporary folder like $HOME/.npm/_npx/35338/lib/node_modules/. Every run is a different temp folder which doesn't have the @pattern-lab/edition-node package installed.

When I first run npm init, followed by npm install create-pattern-lab, it runs correctly because both run from the same node_modules folder.

However, this has an impact on the global user experience. A workaround for now could be that the create-pattern-lab package would only modify the package.json file of the project being created with the dependencies needed based on the user input, but that no resources are copied yet. After the npm create pattern-lab "wizard", the user should execute npm install. We add the correct post-install hook script to some of our packages that copy the resources at that point in time.

Feedback appreciated.

JosefBredereck commented 4 years ago

It could modify the package.json and afterward with start an npm install in that directory. But I don't know if we could easily archive that.