Atm:

This will cause duplicate jQuery dependencie which isn't supported by jQuery

Oh that might be better

Yep, I was hitting my head on those WARNS until I didn't check the npm semver syntax 🙂

With selectize@0.12.6 it can't resolve a valid version:
https://asciinema.org/a/C2XsguyRsXQObmsWHbdH4MeK7

With the pull-request it gets rid of the WARN and satisfies the required dependencies:
https://asciinema.org/a/bT3xwHHaPCrHpVzUOR7YcOFwC (don't pay too much attention to the dyslexic typing...)

About the dependencies / devDependencies, I still believe jQuery to be a runtime dependency.
Am not sure why as devDependencies it would not get duplicated (not sure about the little differences in how dev and non-dev are treated during install).

I couldn't manage to install and get a use case with duplicated versions. But maybe that's also depending on a different NPM version.
In which cases would we get the duplicated dependency that you mention?

devDeps are ignored by upstream deps

Yes, but
devDependencies are for the dev-scripts, e.g. unit testing, packaging, doc generation
dependencies are required for production use, and assumed required for dev as well.

When Selectize is the only project dependency requiring jQuery, no jQuery will be installed on production. There will be a PEER DEP warning (if the user notices that) but why forcing to act manually if there is no conflict?
Especially since our users didn't need to do it until now (= more people opening issues)

jQuery in dependencies will always work as expected from a non-expert user, and will warn just when an unsolvable conflict (duplicate) is found.
In that case the user MUST do something manually and investigate more.

I see most of the other libraries using jQuery to rely (imho correctly) on dependencies and peerDependencies. I think we should do the same.

jQuery is specifically mentioned in the npm docs as a case to use peerDeps

Yes, I am totally fine with jQuery in peerDependencies.

Also npm won't warn on duplicate dependencies. It will just break in production or result in duplicate jQuerys

I meant that it will warn about unsatisfied peerDeps.

I also agree with the idea in this article, that the duplicates case is acceptable since it can be easily resolved, while maintaining compatibility with either NPM 2 & 3.

Thanks for tackling this whole matter @Pictor13, I knew from the start it was going to be a thorny issue. I don't have any bandwidth to study this in depth, @Pictor13 @graingert do we have a consensus to merge?

@joallard no. Do not merge this PR

Thanks. Let me know when you're ready

Don't merge yet.
I have the feeling that choosing the wrong direction here could provoke a lot of problem to old time users. And am not yet 100% convinced of either approach.
We should beware of as much use-cases and setups as possible and try to not create problems to them.

Anyway I add also #1218 to support @graingert point.
Still, @brianreavis answers to it push in the opposite direction. 🤔

I really appreciate that we're taking the time to think about the consequences and that we're trying to reach a solution that makes some kind of consensus. If I can see that and that the changes are reasonable for most users going forward, I'm pretty sure I'll have @brianreavis' support on this.

My understanding of #1218 is that it's been more or less solved by moving jQuery to peerDependencies.

Edit: I put a WIP tag on the title, feel free to remove it when it's ready.