Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NPM packages are installed as dependencies instead of peerDependencies. #864

Closed
arodic opened this issue Sep 2, 2020 · 3 comments
Closed

Comments

@arodic
Copy link

arodic commented Sep 2, 2020

When installing SWC packages with npm i [package], very often packages get installed as nested dependencies and this results with redundant and often broken code in the project (cannot register same element twice).

For this reason, it is important that there is one and only one @spectrum-web-components directory inside node_modules and that all SWC components live right there - next to each other. This prevents the ability to have multiple versions of the same element, and that is a good thing.

I believe the issue is caused by components installing dependent components as "dependencies" while they should be "peerDependencies".

Here one way to reproduce this problem:

  1. Take the starter project from this repo, run npm i @spectrum-web-components/dialog and import it in the project.

  2. Notice that sp-icon is imported twice. Once from node_modules/@spectrum-web-components/icon, and another one in node_modules/@spectrum-web-components/dialog/node_modules/@spectrum-web-components/icon

@Westbrook
Copy link
Contributor

Starting from scratch, when I run:

git clone https://github.com/adobe/spectrum-web-components.git
cp -r spectrum-web-components/projects/example-project-webpack .
cd example-project-webpack
npm i @spectrum-web-components/dialog

I do not experience this problem. It's difficult to confirm, but I would make the assumption that the reason you've run into this situation is that you were running npm i @spectrum-web-components/dialog in a copy of example-project-webpack that was not caught up to main and therefore had diverging versions of packages in it's depependencies listing. Generally, NPM sees the "feature" position in semver as breaking pre-1.0, so the @spectrum-web-components/dropdown@0.7.2 that was available in the project as recently as Friday would have depended on @spectrum-web-components/icon@0.5.2 which NPM would have assumed was markedly different than the @spectrum-web-components/icon@0.6.0 that an install of @spectrum-web-components/dialog@0.3.0 would have required at any point after Monday. So, while these packages do list each other appropriately as dependencies (a peerDependency traditionally outlining a package that you are a "plugin" of rather than a package that you require to work as expected), NPM will have made deep and problem creating decisions as to which versions the meant to depend on.

In this way, the only way to ensure a flat install at current is to use @spectrum-web-components/bundle and deal with the issues that come with that manually in your project (not directly depending on packages you'll likely want to specifically request assets from, the knowledge that you're possibly including EVERYTHING (even when not using everything), etc), or to manually ensure that each time you install a package that ALL packages are pointing to their latest version or that you install a fixed version of your new dependency that matches the tree created by your previous dependencies. 😓 For projects with access to it, dependabot and similar tools, can support managing this reality automatically, which I would highly suggest no matter what next steps we take here.

Separately, were we clean on what's needed to move to 1.0, then we would be able to rely on the fact that post-1.0 NPM only counts major version numbers as breaking and should (though it still has some issues here that are much harder to explain) handle flattening the dependency tree on it's own.

If everything above makes sense, I'd prefer that we close this issue as no action needed and start a new issue of "How do we get to 1.0?" where we can expand on the conversation as to what's needed for us to certify the various packages we are vending as 1.0. Thoughts?

@arodic
Copy link
Author

arodic commented Sep 2, 2020

Thanks for looking into this so quickly @Westbrook!

You are right. It turns out my project is not up to date and some dependencies were not synced. What I had was...

"dependencies": {
        "@spectrum-web-components/button": "^0.8.4",
        "@spectrum-web-components/dropdown": "^0.7.2",
        "@spectrum-web-components/menu": "^0.3.2",
        "@spectrum-web-components/styles": "^0.6.0",
        "@spectrum-web-components/dialog": "^0.3.0",
        "lit-element": "^2.2.1",
        "lit-html": "^1.0.0"
    },

Regardless, even with the latest I notice that there are two copies of sp-button in node_modules. One in @spectrum-web-components/button and another one in @spectrum-web-components/dialog/node_modules/@spectrum-web-components/button but there is no error this time.

I'm OK to close this issue as peerDependencies is not preferred solution but I still think we need a simple way to keep the custom element dependencies flat.

@arodic arodic closed this as completed Sep 2, 2020
@simshanith
Copy link
Collaborator

ref #865

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants