[BUG] Running npm i fails with Cannot read properties of null (reading 'isDescendantOf')
#5687
Open
2 tasks done
Labels
Bug
thing that needs fixing
Priority 2
secondary priority issue
Release 8.x
work is associated with a specific npm 8 release
Comments
fatso83
added
Bug
fritzy
added
Priority 2
|
Theoretically, links shouldn't be an issue. This is worth fixing. |
|
I'm also having this issue. In a workspace I have to run I also have a similar problem when not using |
trusktr
added a commit
to lume/autolayout
that referenced
this issue
Oct 24, 2023
trusktr
added a commit
to lume/cli
that referenced
this issue
Oct 24, 2023
trusktr
added a commit
to lume/cli
that referenced
this issue
Nov 5, 2023
…rettier' * remove-global-builds-switch-to-web-test-runner-update-prettier: (29 commits) feat: fallback to loading jest globals in test-runner from the hoisted node_modules location if it is not located in lume/cli's node_modules BREAKING: add a check to ensure that the repo is not modified before versioning during release. Repo author should be sure to commit build outputs, or fix the build so no changes happen during build that are not tracked. undo testing in firefox and safari for now, some lume code needs fixing BREAKING: besides Chromium, also run tests in Firefox and Safari in CI. Migration: If you didn't test those browsers before, you might have to update any code that is not compatible. Alternatively, make sure there is no CI env var set and it will test in Chrome only. update test-runner port range to avoid ports denylisted by Chrome install web test-runner's playwright launcher, and use that to run tests in Chrome in CI run tests on a random port to avoid collisions when running tests in parallel for multiple projects at the same time BREAKING: migrate from Karma to `@web/test-runner`. This removed a lot of dependencies (namely Webpack needed for the Karma setup), greatly reduces maintenance burden, speeds tests up, provides a much simpler and better test development and debugging experience with minimal configuration compared to with Karma, and ensures longevity of test code by ensuring that they run as standard JavaScript modules. 🎉 The `webpackConfigs` and `testSpecFormat` options for `lume.config.cjs` have been removed. Migration: Delete any webpack configs, all code should be vanilla JavaScript (ES) modules. There is only one test spec format now (Mocha `describe()`/`it()` and Jest `expect()`). Test syntax is mostly the same, and most tests will remain as-is. A few things need to be changed from Jasmine's `expect()` API to Jest's very similar `expect()` API. For example, `expect(true).toBeTrue()` needs to be changed to `expect(true).toBe(true)`. `jasmine.*` API is removed, f.e. `jasmine.createSpy` can be replaced with `sinon.spy()`. Try running tests, see what broke, then look up the way to do it with Jest or with Sinon, etc. Also tests are executed as vanilla ES Modules in a browser, and an `importMap` field will need to be defined in `lume.config.js` to handle bare specifiers (f.e. the `foo` in `import something from 'foo'`). Only ES Modules are supported, so if any libraries are CommonJS, those will not work and alternatives will be needed. The CLI can be forked though, and `@web/test-runner`'s config can be expanded to use its built-in `esbuild` plugin, along with Rollup plugins for any non-vanilla-ESM use cases. BREAKING: instead of trying to stash changes and continuing with versioning and publishing, exit non-zero if the working directory is dirty. Migration: clear your git repo of changes, then try again. update version scripts to avoid an issue with workspaces and linked dependencies (npm/cli#5687, npm/cli#4787) BREAKING: remove the global build feature, from now on we output and publish only JS modules for simplicity. Migration: @lume/cli will no longer output global.js files for use with non-module script tags, instead any code depending on your @lume/cli-managed package should use `import` syntax to import your package. port karma bash script to Node so it works in Windows too ensure line endings match with the rest of our tooling (all work in LF) ensure that we also get tsc, babel, and prettier bins with Node module lookup to avoid relying on PATH (Yarn and NPM set PATH differently, see Yarn issue 5800) update exec calls to find binaries using node_module resolution instead of relying on PATH to prevent cross-platform issues with Windows, and make the noFailOnError option use || echo '' instead of || true for cross-platform support prevent duplicate solid-js libs. Its ok to hard code this one case, because solid-js is a key dependency of lume Avoid error with fs.mkdir if dir already exists. Why is it so difficult? ensure dist/ is created before we copy assets to hopefully solve a problem with this in Windows CI (https://github.com/lume/lume/actions/runs/6519881972/job/17706893670) update prettier to 3.0.3 infra: add .gitattributes with rules to enforce that code is checked out with LF line endings only, which prevents Prettier from failing in Windows ...
|
@fritzy this isn't only about links. I have no links in |
trusktr
added a commit
to lume/cli
that referenced
this issue
Nov 22, 2023
|
getting a similar error trying to run |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Is there an existing issue for this?
This issue exists in the latest npm version
Current Behavior
When installing a project using PNPM first and then subsequently using standard
npmto install it, the install process borks after a long time with:Looking at the generated debug log one can see a null pointer being mentioned:
Adding a
console.log("link.target is null!", link)just before it fails shows this:This points at one of the PNPM installed files being an issue of some sort. Maybe due to the symlinks created?
Expected Behavior
I would expect that NPM would go about its business and handle the situation where PNPM previously has stepped all over its turf gracefully 😄
It took some attempts (actually writing this) to discover that wiping with
rm -r node_moduleswould fix the issue, so maybe one could add some heuristics to detect weird symlinks where there should not be and just delete the directory before re-installing? That would be very user friendly, at least.Steps To Reproduce
hub clone fatso83/example-encrypt-properties(clone this repo)cd example-encrypt-properties && pnpm i && npm inpm ERR! Cannot read properties of null (reading 'isDescendantOf')Environment
The text was updated successfully, but these errors were encountered: