search

chiubaka / genesis

Creates standardized monorepos and pre-configured project scaffolding for Chiubaka Technologies projects.
2 stars 0 forks source link

`@chiubaka/nx-plugin` disappears from dependencies when running multiple lib generators on the same workspace during E2E tests #110

Closed chiubaka closed 2 years ago

chiubaka commented 2 years ago

Not sure why, but as part of the solution to #84, I now have a specific workspace just for E2E testing libraries. Oddly, if I run one library E2E test on it it works fine. If I try to run multiple E2E tests on it (even using --runInBand), the second lib test always fails with errors about not being able to locate @chiubaka/nx-plugin. When checking node_modules, I can then confirm that @chiubaka/nx-plugin is not there.

This is likely to block addition of new library generators in #98. It's also blocking addition of E2E tests for #108.

chiubaka commented 2 years ago

A bit of testing makes me suspect that this is happening because I'm trying to run these E2E tests inside the workspace that has @chiubaka/nx-plugin, creating complexities around module resolution and install that are rather awkward. This doesn't seem to happen if I copy the directory out of the workspace (e.g. into /tmp) and then clear node_modules, yarn.lock and the global yarn cache.

My latest idea is to potentially generate all files for E2E testing in /tmp and actually operate on them within /tmp, and then simply symlink those directories into the E2E tmp directory.

chiubaka commented 2 years ago

Wait lol. This is totally happening because of my post-install command to remove @chiubaka/nx-plugin from node_modules, which is sitting in the root monorepo.

I didn't realize this was get run for projects in subdirectories... I also don't entirely remember why I needed that there in the first place.

chiubaka commented 2 years ago

I tried removing the postinstall scripts and I think it's had a positive effect on the project overall? E2E tests still seem to be pulling a built version of the nx-plugin package, which is desired.

Will keep this this way for now and monitor for issues over the next week.

chiubaka commented 2 years ago

Ok, I remember why I was doing the postinstall in the first place now. It's because I wanted to be able to use the @chiubaka/nx-plugin:publish-local executor, but if yarn workspaces symlinks the current unbuilt version of @chiubaka/nx-plugin into node_modules, then Nx's code attempts to require a TS module, which doesn't work.

Any workaround that still deletes the @chiubaka/nx-plugin node module (or symlinks the dist directory instead) will work so long as it doesn't interfere with sub-workspace installs. For example, a target that specifically just rm -rfs this node module could work.

chiubaka commented 2 years ago

Closed by #113.