update controls import

[RaulPROP]

I have updated the controls so the users can access new features as in this issue.

I also added a .gitignore file.

[sirrodgepodge]

can't you just import from three? not the example code? The actual three dependency is up to date btw (I checked that when trying to debug)

[RaulPROP]

I tried to, but node couldn't find the object. The only part of the code where the controls are exported are on the example folder.

Also I did a fast research and found that on the threejs examples they export them from that path.

[sirrodgepodge]

wow looks like it, opened an issue here: mrdoob/three.js#19250

[sirrodgepodge]

okay it actually looks like this is the approved way to do it:
mrdoob/three.js#19250 (comment)

[vasturiano]

Thanks @RaulPROP for this. I think it would be certainly a good shift to consume the controls directly from the three package.

However this is a bit of a problematic approach, because three is not a dependency of this module, but a peerDependency. That means it's not guaranteed to be available for import at bundle time and is expected to be provided by the consumer.

In the UMD version this takes the form of the consumer including a script tag which exposes a global understood by the bundler (rollup).

Since the controls are not exposed as part of the core three build, things gets a bit complicated. We could either:

1. Shift three to a regular dependency instead of peerDependency. This is highly undesirable as it would over bloat the module bundle size. It would also prevent the consumer from having a single instance of three in the application, since it's very likely this lib will be used side by side with other three functionality.

2. Expect the UMD consumers to include additional script tags for all the controls used in the module, and register all of those as expected globals in rollup. This requirement would be confusing for the users imo, and would lead to quite a bit of head-scratching and unexpected hard to debug linking issues, because the need for it is not really apparent.

3. Include three as devDependency in addition to peerDependency. This is probably the most promising of all the options, but it is kind of hackish as that's not really the main use of devDependencies. And I'm also not 100% sure is not gonna lead into dependency conflicts upstream.

I'm inclined to give 3) a try, unless you can think of a better way to approach it.

Hopefully it's clear why this is a less straight-forward change than it immediately appears. This is the reason why I initially went the route of importing the controls from separate packages, because you can then separate the peer from the regular dependencies.

[RaulPROP]

Oh, I didn't notice this problem.

I don't know which one is the best solution, I don't have much experience dealing with this situations.

Maybe we could create a fork of the libraries that this package is currently using and update the code to match the three.js/examples ones?

[vasturiano]

Ok I went with option 3). Also removed the stand-alone dependencies since they're no longer used.

Thanks!