chore: manually hoist dev dependencies

[dyladan]

More build time cleanups and tooling improvements.

• tsc installed in the root only
• eslint installed in the root only
• gts gone (including its many dependencies)
• all types moved to the root so they aren't installed in every project
• One central eslint configuration for all packages

[codecov[bot]]

Codecov Report

Merging #1770 (61d50ff) into main (dc38495) will increase coverage by 0.00%. The diff coverage is n/a.

@@           Coverage Diff            @@
##             main    #1770    +/-   ##
========================================
  Coverage   92.30%   92.31%            
========================================
  Files         157      163     +6     
  Lines        5122     5413   +291     
  Branches     1089     1158    +69     
========================================
+ Hits         4728     4997   +269     
- Misses        394      416    +22     

Impacted Files	Coverage Δ
...ages/opentelemetry-exporter-collector/src/types.ts	100.00% <ø> (ø)
...etry-exporter-prometheus/src/PrometheusExporter.ts	91.04% <0.00%> (-1.50%)	:arrow_down:
...lemetry-exporter-collector/src/transformMetrics.ts	95.00% <0.00%> (ø)
...rumentation/src/platform/browser/old/autoLoader.ts	100.00% <0.00%> (ø)
.../opentelemetry-exporter-collector/src/transform.ts	87.85% <0.00%> (ø)
...kages/opentelemetry-exporter-collector/src/util.ts	100.00% <0.00%> (ø)
...ry-exporter-collector/src/CollectorExporterBase.ts	92.45% <0.00%> (ø)

[dyladan]

Cache hit build times

Cache miss build times

[dyladan]

have you tried lerna hoist option - it doesn't install then all node_modules in each package but in main folder

  "command": {
    "bootstrap": {
      "hoist": true
    }
  }

The hoist option breaks the plugin tests. I worked for a while to try to figure out what was broken but in the end I gave up.

[obecny]

@dyladan why did you add package-lock.json again?

[dyladan]

@dyladan why did you add package-lock.json again?

Only the one at the root of the project. Since these are not cross-linked in any way and don't change regularly it is worth the speed tradeoff.

edit: also this is not bringing it back. it was never removed.

[obecny]

@dyladan why did you add package-lock.json again?

Only the one at the root of the project. Since these are not cross-linked in any way and don't change regularly it is worth the speed tradeoff.

I thought we already been there. It will still have the same problem just in smaller scale now. Locally you will have this file anyway so it will speed up yr local build, but at least you don't have to worry about any merging conflicts. I would like to have 0 conflicts and to see what really changed in certain PR.

[obecny]

edit: also this is not bringing it back. it was never removed.

You meant it wasn't removed with other locks files just recently which I think should be removed, it was missed.

[dyladan]

edit: also this is not bringing it back. it was never removed.

You meant it wasn't removed with other locks files just recently which I think should be removed, it was missed.

it wasn't missed it was intentionally kept. the lockfiles in packages were causing problems mostly because lerna didn't understand how to deal with them. the root dependencies aren't lerna managed so this isn't a problem. you can use something like npm-merge-driver to automatically handle package-lock.json merge conflicts locally so you don't have to think about this.

[pichlermarc]

As far as I can tell, most of the points this PR addresses are already done and it would be a pain to rebase this.

From what I can see two things that have not been yet done are:

• all types moved to the root so they aren't installed in every project
• One central eslint configuration for all packages

Should we close and create some issues for these two points? WDYT @dyladan? :thinking:

[dyladan]

central eslint config is also done and devdeps are hoisted so even that would be duplication i think