Closed ringods closed 3 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.
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.
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
andfetchPackage
:https://github.com/pattern-lab/patternlab-node/blob/f4d6bd1fd2afd3cb4403350f24d747e44c54cd6c/packages/cli/bin/utils.js#L125-L166
@sghoweri @JosefBredereck