npm Community Forum (Archive)

The npm community forum has been discontinued.

To discuss usage of npm, visit the GitHub Support Community.

[Solved] Extraneous package

Just adding a new answer to the thread I opened time ago, to actually close it :expressionless:

(see the second post below)

– Addendum –

“Polemic” digression:

I wanted to just add the closing answer to a thread I opened in Support, but the settings of the forum are pretty restrictive.

I dunno why threads have been set to lock so quickly, not even allowing the authors itself to add anything to them.
It is limiting the progression of discussion: people with an answer will not be able to write it and help people in the future, because not many will be willing to open a new thread just to add something. The chronology of an issue or of a resolution is being scattered in different threads, without continuity.

Am I the only one sharing these concerns? It feels like questions will have to be asked again and again, creating garbage threads, containing just one question, and hopelessly locked after short time.
There are already 2-3 threads that I incurred in the last couple of weeks that I wanted to answer to, in order to share what I learned and to save hassles to people in the future that are looking info on inconsistent behaviours of NPM (specifically, version 5).
Same, I wanted to update my thread, but looks like I wasn’t “quick enough” to solve my issue, cause the thread has been locked :roll_eyes:
Same approach have been taken with the Issue section of the old npm/npm repository, leaving important topics/issues/bug-tracing suspended, (apparently) unresolved, and taking out the chance to anybody to add constructive info or warnings.

I am just writing this because I am wondering if this is a specific approach (with what purpose?) or if it is just the result of a quick setup or quick transition.
Doesn’t look optimal for the end-user that looks for support and help (here and on the old npm/npm).
The only advantage I see is just for the moderators that have less cluttering of open threads; but if that is the problems I’d suggest a more extended use of tags, rather than “labelling” threads as still relevant or not just purely based on how much time passed from the last interaction.
Also, the ultimate paradox is that I am opening a third thread on the same argument, to extend my last opened one, that actually was already extending another thread because it was locked and I didn’t have a chance to write or ask clarifications there.

Does anybody has the same feel and thinks that this new forum might be improved in how it can serve the

Answer to:

shadowspawn John Gee said:

It is not normal.
(From looking at one of your other topics, I wonder if custom-repoC is not the package name as specified in reboC . But that is a guess!)

The problem was exactly that, thank you for the suggestion!

It wasn’t clear to me, from the documentation, that the declared name inside package.json of the installed dependency MUST match the name/key of the corresponding installed package inside the project.

// project package.json
  "dependencies": {
    "exact-pagckage-name": "as-in-the-package-json-of-this-lib"

At first look I’d say changing the key of the pair would give me control on the installation path under node_modules for the dependency.

Indeed I was using it that (guessed) behaviour to install the dependency (specified as @scopeA/repoC in its package.json 's name field) under node_modules/repoC rather than under a nested scoped directory node_modules/@scopeA/repoC.

The tricky thing is that with NPM5 the package was just silently skipped with no feedback whatsoever.
It actually worked that way (can’t remember on which NPM verson, but might be 5) running npm install --global-style and npm dedupe, not nesting in @scopeA; leading me to believe that this was an allowed configuration.

In fact, except for the extraneous tag displayed on npm ls, there was no real info during installation in order to debug the problem.

Ensuring that the installed name is exactly the same as the name declared in the dependency’s package.json, as you suggested, fixed the issue.
I think the documentation might be more explicit about this requirement (or can anybody point me to where this is highlighted?).

For the future, I suggest to everybody to rely on npm install --save <git-url> to add the dependency and not incur in this puzzling problem.

In brief response to the digression:

Oh, I totally missed #meta :thinking:. Thanks again for the diverse help you are providing me!