Add support for custom npm packages about wasp HOT 3 CLOSED

Two main approaches:

1. User specifies npm packages they want to add as dependencies, but if one of them is already brought by wasp, they get a warning "This package is already installed by Wasp, version a.b.c, you can just import it and use it".
   Bad thing here is that they can't choose version of these packages, nor can they choose when will they be updated -> if major version of Wasp changes, versions of these packages might also likely change, and then there will be a lot of things to update at once, while user might have wanted to do these upgrades separately in smaller steps or not do them at all
   Good thing is, generated code is uniform / same library is used through the whole codebase.
2. We use npm aliases which allows using multiple different versions of the same package by aliasing them. We could let user know that Wasp is already using certain package, in case they would rather use version Wasp is already using, to avoid unnecessary code being bundled into project, but if they want different version, they can do it -> we just need to ensure that wasp uses different alias for it, for example it could normally address react as react but if user imported another version of it (that user calls react) then wasp can call it react-wasp. This is more flexible approach but it requires more work.

Challenges:

• What if user needs lodash, but wasp is already using it, so they don't add it as dependency because Wasp is already bringing it, and then with some upgrade of Wasp, Wasp stops using lodash, and suddenly code is failing because that dependency is missing? Answer is, they should still declare it as dependency, even if Wasp is bringing it! We can just inform them that .e.g. they can use only very specific version (if going with approach 1) or that they might want to use specific version to avoid double dependency (approach 2).
• How will use specify these packages? Will there be dependencies JSON block they can specify? Where? In some kind of package.json? In .wasp file? What about dev dependencies vs just dependencies? What about client dependencies vs server dependencies?

from wasp.

For first iteration, it is probably best to go like this:

1. Approach 1, where if user wants to add existing dependency, they have to list it, but they are forced to use specific version that Wasp says they have to use. Later, we will allow them to use any version by upgrading implementation to Approach 2, where they will get suggestion to use same version as Wasp, but will be free to use any version they want.
2. Dev dependencies are not important at the moment since Wasp is completely hiding that part, so we will go just with dependencies.
3. Client vs Server -> we can just put it all together for now and figure out later how to optimize that? Yes, let's do it like this for now, and when problems arrive, we will handle them.
4. How will dependencies by defined -> they could go in *.wasp file, or in wasp-dependencies.json or smth like that. Ok, for now, we are going with wasp element in *.wasp file: dependencies {=json ... json=}, very simple, and we can improve it in the future.

from wasp.

Done with #58 .

from wasp.