refactor(shared-data): Enumerate standard labware by globbing instead of hard-coding

[SyntaxColoring]

Overview

We have some functions that return all the Opentrons standard labware definitions in shared-data. These functions were implemented basically by hard-coding a great many import .../foo.json statements and returning those objects. This was obviously tedious and type-unsafe, and it would get worse with the introduction of labware schema 3.

This PR replaces that with some glob imports, a Vite-specific feature.

This goes towards EXEC-1278.

Changelog

There are 3 functions exported from this file:

• getAllLabwareDefs()
  • Now returns the in-development opentrons_flex_96_tiprack_20ul and opentrons_flex_96_filtertiprack_20ul definitions, which were previously excluded. To compensate, these have been added to LABWAREV2_DO_NOT_LIST and PD_DO_NOT_LIST.
  • No longer returns opentrons_flex_tiprack_lid. This should never have been returned in the first place because this definition is a LabwareDefinition3, whereas the function says it returns only LabwareDefinition2s. This function should return LabwareDefinition3s too, but that will require updates to calling code and is beyond the scope of this PR. See EXEC-1278.
• getAllDefinitions()
  • As above, now returns opentrons_flex_96_tiprack_2ul and opentrons_flex_96_filtertiprack_20ul.
  • As above, no longer returns opentrons_flex_tiprack_lid.
  • The keys of the returned record are now definition URIs like opentrons/axygen_1_reservoir_90ml/1, instead of internal TypeScript identifiers like axygen1Reservoir90MlV1.
• getAllLegacyDefinitions()
  • No change.

Review requests

• Is it OK to return opentrons_flex_96_tiprack_20ul and opentrons_flex_96_filtertiprack_20ul now?
• Is it OK to not return opentrons_flex_tiprack_lid now?
  • Is there anything I should test for this?
• Any concerns with using glob imports? In particular, because this is a Vite-specific feature, shared-data and its consumers are now dependent on Vite. A consumer either needs to use a Vite-bundled dist of shared-data, or it needs to be bundled by Vite itself, I think.

Test Plan and Hands on Testing

• opentrons_flex_96_tiprack_20ul and opentrons_flex_96_filtertiprack_20ul remain excluded from:
  • Labware Library
  • Protocol Designer

Risk assessment

Medium.

[codecov]

Codecov Report

Attention: Patch coverage is 95.23810% with 2 lines in your changes missing coverage. Please review.

Project coverage is 25.67%. Comparing base (e583471) to head (6b1ecfc).
Report is 10 commits behind head on edge.

Files with missing lines	Patch %	Lines
shared-data/js/labware.ts	94.44%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             edge   #17631      +/-   ##
==========================================
- Coverage   25.68%   25.67%   -0.02%     
==========================================
  Files        2851     2851              
  Lines      219457   219305     -152     
  Branches    17971    18021      +50     
==========================================
- Hits        56363    56300      -63     
+ Misses     163079   162990      -89     
  Partials       15       15              

Flag	Coverage Δ
protocol-designer	18.89% <95.23%> (-0.05%)	⬇️
step-generation	4.30% <95.23%> (-0.08%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
shared-data/js/getLabware.ts	67.96% <100.00%> (+1.29%)	⬆️
shared-data/js/helpers/index.ts	55.47% <100.00%> (+0.15%)	⬆️
shared-data/js/labware.ts	94.73% <94.44%> (+12.39%)	⬆️

... and 21 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[shlokamin]

looks like you were trying to import from the private export. since you are outside of the helpers module, i think you want to import from the public export. i just pushed up a small commit to do that

[shlokamin]

thanks for doing this! this is way better.

[shlokamin]

uh nevermind let me see what's going on

[shlokamin]

you are correct, there are indeed a few circular dependencies. we should really move all of these helpers into their own files, in the meantime duplicating is fine