chore: moving all @types dependencies to dev dependencies

[rusackas]

SUMMARY

As per a chat with @etr2460 I figured it's worth trying to move all these to dev dependencies and see if CI explodes :)

BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF

TEST PLAN

🤞 CI

ADDITIONAL INFORMATION

• Has associated issue:
• Changes UI
• Requires DB Migration.
• Confirm DB Migration upgrade and downgrade tested.
• Introduces new feature or API
• Removes existing feature or API

[rusackas]

Welp, this seems to work so it passes the curiosity test. Wondering if @ktmud or @suddjian or anyone else with more miles clocked on their TypeScipt odometer would consider this PR a good or bad idea. ¯\_(ツ)_/¯

[etr2460]

i think this is fine as the types should only be required for development and running build scripts.

But i agree, @ktmud or @kristw might know better what's best here

[ktmud]

My understanding is @types/* should always be in dependencies for libraries because you don't want your dependent package to not have out-of-the-box typing---it may be hard for library users to keep track of which additional @types/* are needed.

Since all NPM packages are presumed to be a "library" if they are going to be published, we always put @types in dependencies by default.

For the superset-frontend app though, or any other npm-managed frontend apps for that matter, is not going to be published as a library, so it's OK to put @types in either place. In fact, one may even argue it's probably preferred to put all dependencies (including babel, webpack, jest, etc) in only one of dependencies or devDependencies, since

1. If we consider the source code the published product of the app, we may want NODE_ENV=production npm install && npm build to work as well. So dependencies is preferred.
2. If we consider the built assets the published product of the app, we may want to put them all in devDependencies for consistency and simplicity.

[rusackas]

My understanding is @types/* should always be in dependencies for libraries because you don't want your dependent package to not have out-of-the-box typing---it may be hard for library users to keep track of which additional @types/* are needed.

Since all NPM packages are presumed to be a "library" if they are going to be published, we always put @types in dependencies by default.

For the superset-frontend app though, or any other npm-managed frontend apps for that matter, is not going to be published as a library, so it's OK to put @types in either place. In fact, one may even argue it's probably preferred to put all dependencies (including babel, webpack, jest, etc) in only one of dependencies or devDependencies, since

1. If we consider the source code the published product of the app, we may want NODE_ENV=production npm install && npm build to work as well. So dependencies is preferred.
2. If we consider the built assets the published product of the app, we may want to put them all in devDependencies for consistency and simplicity.

I'm inclined to go with #2 for the time being. We can always adjust later if the game changes. At least they should all be in one spot, to avoid further confusion, so it's a step in A direction ;)