build(components, shared-data): fix components and shared-data npm deploy actions

[shlokamin]

Overview

Since the vite migration our npm publish github action has been publishing an unusable artifact for the following reasons:

1. The main entry path points to the old bundle name that webpack generated
2. We do not specify all dependencies required for consumers to use @opentrons/components, which leads to build errors when trying to import modules that don't exist
3. Image urls configured via the new URL() constructor do not point to an asset that is bundled into the production build. This means we get an import error when a consumer builds their project because it can't find assets we reference in our code. Ex:

new URL("./images/depth/depth-plate-flat@3x.png", import.meta.url).href,

^this works fine in development, but in a production build we'll get an error like this:

ERROR in ./node_modules/@opentrons/components/lib/index.mjs 16968:15-78
Module not found: Error: Can't resolve './images/depth/depth-plate-v@3x.png' in '/Users/shlokamin/Desktop/workspace/my-app/node_modules/@opentrons/components/lib'

It turns out that the way vite interprets:

const FOOTPRINT_RELATIVE_PATH = './images/dimensions/footprint@3x.png'
new URL(FOOTPRINT_RELATIVE_PATH, import.meta.url)

// versus

new URL('./images/dimensions/footprint@3x.png', import.meta.url)

is... different. Vite does not like the first option, but it is okay with the second option. tbh im confused as to why, since the calls to the URL constructor are evaluated immediately (not lazily).

Anyways, this PR fixes these issues.

Review Requests

Try out version 0.1.6-alpha.7 of the components library and see if it works for y'all

Risk assessment

Low/medium

[sfoster1]

Looks good to me. What a weird constraint

[TamarZanzouri]

LGTM and works when importing! sorry i forgot to approve!

[b-cooper]

🥇