Vendor common dependencies into the repository #6203
Comments
|
@mathiasbynens @paullewis @OrKoN @hanselfmu PTAL :) |
|
Do you expect this to only apply to mitt, or other dependencies? I don't know of any other way of doing this besides rolling in a |
|
It looks like Mitt does not have any dependencies, and seems like a single build can work in both the browser and Node, so this solution seems quite promising, at least for this interim period. And I agree that we should be careful about adding other common dependencies, because not all the libraries out there are as self-contained as Mitt 😃 |
It would apply to any common dependencies - that is, ones that are used in both the browser and Node version of Puppeteer.
This is a good point, if Mitt had 5 dependencies, we'd have a bigger challenge on our hands. I hope we can avoid this and keep our dependencies down to a minimum. In our case Mitt being tiny really helps. As @paullewis says I can't think of another way to do this; I'll put together a proof of concept to see how hard/easy/painful/etc it is. |
As discussed in #6203 we need to vendor our common dependencies in so that when we ship an ESM build all imports point to file paths and do not rely on Node resolution (e.g. a browser does not understand `import mitt from 'mitt'`).
As discussed in #6203 we need to vendor our common dependencies in so that when we ship an ESM build all imports point to file paths and do not rely on Node resolution (e.g. a browser does not understand `import mitt from 'mitt'`).
As discussed in #6203 we need to vendor our common dependencies in so that when we ship an ESM build all imports point to file paths and do not rely on Node resolution (e.g. a browser does not understand `import mitt from 'mitt'`).
* chore: vendor Mitt into src/common/third-party As discussed in #6203 we need to vendor our common dependencies in so that when we ship an ESM build all imports point to file paths and do not rely on Node resolution (e.g. a browser does not understand `import mitt from 'mitt'`).
|
We're marking this issue as unconfirmed because it has not had recent activity and we weren't able to confirm it yet. It will be closed if no further activity occurs within the next 30 days. |
|
I believe this one is fixed. |
We are currently working on shipping a browser build. #6202 fixes one of the issues @paullewis found; we need file extensions on our imports to match the ESM spec.
The next challenge is the import of dependencies that we use in any environments. The only dependency we have currently that's common to all environments is Mitt. Right now our bundled code ships as
import mitt from 'mitt'but a browser has no idea whatmittrefers to and how to resolve it.importMaps may provide a solution in the future but they are not at a point to be relied on yet.
I'm proposing that we vendor any common dependencies into this repository. This means we can import them as
import mitt from './common/third_party/mitt/mitt.es.js(exact path TBC) and that will work in the browser and Node equally well.The downside is we have to manage these dependencies but I think our list of dependencies will be very small; the vast majority of Pptr's dependencies are for extracting files from zips/DMGs/etc and I think as a rule we'll be very considered about adding new common dependencies in the future. If needed we can introduce some scripts to make managing them and updating them easier (like we have in DevTools-Frontend).
The text was updated successfully, but these errors were encountered: