v7.10.1 import issue

[KayakinKoder]

Description

v7.10.1 created the following problem when importing video.js as an es module.

Steps to reproduce

Explain in detail the exact steps necessary to reproduce the issue.

1. Install v7.10.1
2. Import video.js es6 style e.g. import vjs from 'video.js';
3. Using rollup to bundle (likely also other bundlers, webpack etc) you'll get the following errors

Results

Expected

No error occurs

Error output

'@videojs/vhs-utils/dist/containers' is imported by node_modules\video.js\dist\video.es.js, but could not be resolved – treating it as an external dependency '@videojs/vhs-utils/dist/byte-helpers' is imported by node_modules\video.js\dist\video.es.js, but could not be resolved – treating it as an external dependency No name was provided for external module '@videojs/vhs-utils/dist/containers' in output.globals – guessing 'containers' No name was provided for external module '@videojs/vhs-utils/dist/byte-helpers' in output.globals – guessing 'byteHelpers'

[welcome]

👋 Thanks for opening your first issue here! 👋

If you're reporting a 🐞 bug, please make sure you include steps to reproduce it. We get a lot of issues on this repo, so please be patient and we will get back to you as soon as we can.
To help make it easier for us to investigate your issue, please follow the contributing guidelines.

[gkatsev]

Thanks for the issue, we're aware of it, and we'll try to fix it quickly. In the meantime, feel free to go back to using 7.9.7 or if you can pin @videojs/vhs-utils to version 2.2.1, that should resolve the issue as well.

[gkatsev]

Hey everyone, thanks for your patience. We got distracted due to the demuxed conference last week.
I've released Video.js 7.10.2 earlier today which should fix the vhs-utils issue. Please try it out and report issues if you find any.
Thanks!

[ryan-rushton]

I am seeing this issue with 7.11.4 as well, should I open a new issue?

[Roywcm]

I'm also experience the same issue.

[matrunchyk]

Same issue with 7.11.4. Which one is a working one? Tried 7.9.7, but also no luck.

[matrunchyk]

Ok, npm install @videojs/vhs-utils@2.2.1 does the trick.

[gkatsev]

@matrunchyk are you using yarn 2?

[ryan-rushton]

@gkatsev I wasn't

edit: 1.22.10 for reference

[matrunchyk]

@gkatsev
npm 6.14.11
node v12.21.0

[gkatsev]

@ryan-rushton interesting. Is yarn choosing vhs-utils 3.x?
Also, try following the process outlined here for updating video.js: #7091 (comment)

[gkatsev]

@matrunchyk weird, was it choosing vhs-utils 3 previously?

[matrunchyk]

@gkatsev yes sir, 3.0.0 with no mentioned helpers in the dist folder.

[gkatsev]

huh, weird, I don't understand why vhs-utils 3.x is being chosen. Afaik, eveything has vhs-utils 2.x in the dependencies field...

[matrunchyk]

ahh found out. m3u8-parser@4.6.0

[matrunchyk]

Is m3u8-parser@4.6.0 compatible with the latest video.js?

[gkatsev]

What version of Video.js are you using? I think m3u8-parse 4.6.0/vhs-utils 3 should work with Video.js 7.11.7.
I'll spend some time tomorrow trying to figure out the whole dependency tree and what's going on here.

[matrunchyk]

I'm on video.js@7.11.4

Here is my deps tree:

[gkatsev]

Thanks, @matrunchyk are you using m3u8-parser directly as well?

[matrunchyk]

Correct, m3u8-parser@4.6.0

You're right, perhaps I should not use it directly. Removed m3u8-parser and @videojs/vhs-utils from my package.json and it works like a charm!

Thank you!

[gkatsev]

Cool, yeah, if you need m3u8-parser you'd need to use the same version that your version of Video.js/VHS is using.

Either way, I think I need to look through things as there may be some weird version mismatches.

[ryan-rushton]

FWIW, I just removed my vhs-utils dependency, installed the latest video.js, and it seems to be fine now. I have m3u8-parser v4.5.0. I can't remember if I had m3u8-parser installed separately when I initially wrote my comment.

[tzarebczan]

Still running into this. The workaround helps, but that shouldn't be the solution to this. What's the actual fix on the videojs side?

[gkatsev]

The last thing I can think of is bringing the VHS dependencies as Video.js dependencies, if that doesn't fix yarn then I'm not sure if there's anything we can do.
I hope that we'll have it in the next minor release of Video.js.

[gkatsev]

tl;dr, yarn is doing things differently than npm, you can use https://github.com/atlassian/yarn-deduplicate after adding a new version of Video.js to fix up versions.

---

OK, I think I finally have a handle on this, and it has to do with how yarn handles version matching and differences between it and npm.
Currently, 7.13 is a prerelease version, meaning it isn't latest tag on npm.
In npm, with a test project, that depends on video.js and videojs-contrib-quality-levels, I can install Video.js 7.12 which is latest.

$ npm i video.js@7.12
$ npm ls video.js
videojs-bundler-sample@1.0.0 /Users/gkatsevman/p/videojs-bundler-sample
├─┬ video.js@7.12.3
│ └─┬ @videojs/http-streaming@2.8.2
│   └── video.js@7.12.3  deduped
└─┬ videojs-contrib-quality-levels@2.0.9
  └── video.js@7.12.3  deduped

There, we can see that Video.js is deduped as expected.
When I update to Video.js 7.13, it gets updated and deduped as expected as well.

$ npm i video.js@7.13
$ npm ls video.js
videojs-bundler-sample@1.0.0 /Users/gkatsevman/p/videojs-bundler-sample
├─┬ video.js@7.13.0
│ └─┬ @videojs/http-streaming@2.9.0
│   └── video.js@7.13.0  deduped
└─┬ videojs-contrib-quality-levels@2.0.9
  └── video.js@7.13.0  deduped

However, going back to Video.js 7.12, and then updating to Video.js 7.13, I get (tripped output)

yarn why video.js
yarn why v1.22.10
[1/4] :thinking_face:  Why do we have the module "video.js"...?
[2/4] :truck:  Initialising dependency graph...
[3/4] :mag:  Finding dependency...
[4/4] :aerial_tramway:  Calculating file sizes...
=> Found "video.js@7.13.0"
info Has been hoisted to "video.js"
info This module exists because it's specified in "dependencies".
=> Found "videojs-contrib-quality-levels#video.js@7.12.3"
info Reasons this module exists
   - "videojs-contrib-quality-levels" depends on it
   - Hoisted from "videojs-contrib-quality-levels#video.js#@videojs#http-streaming#video.js"
=> Found "@videojs/http-streaming#video.js@7.12.3"
info Reasons this module exists
   - "video.js#@videojs#http-streaming" depends on it
   - Hoisted from "video.js#@videojs#http-streaming#video.js#@videojs#http-streaming#video.js"

Weirdly, going back to an older version of Video.js, I get version mismatched:

$ yarn add video.js@7.11
$ yarn why video.js
yarn why v1.22.10

=> Found "video.js@7.11.8"
info Has been hoisted to "video.js"
info This module exists because it's specified in "dependencies".
=> Found "videojs-contrib-quality-levels#video.js@7.12.3"
info Reasons this module exists
   - "videojs-contrib-quality-levels" depends on it
   - Hoisted from "videojs-contrib-quality-levels#video.js#@videojs#http-streaming#video.js"
=> Found "@videojs/http-streaming#video.js@7.12.3"
info Reasons this module exists
   - "video.js#@videojs#http-streaming" depends on it
   - Hoisted from "video.js#@videojs#http-streaming#video.js#@videojs#http-streaming#video.js"

Now, installing video.js 7.12, the latest video.js, works fine:

$ yarn add video.js
$ yarn why video.js
yarn why v1.22.10
=> Found "video.js@7.12.3"
info Has been hoisted to "video.js"
info Reasons this module exists
   - Specified in "dependencies"
   - Hoisted from "videojs-contrib-quality-levels#video.js"
   - Hoisted from "video.js#@videojs#http-streaming#video.js"

So, I think the issue arises when a non latest version of Video.js is added. yarn doesn't automatically dedupe the packages for whatever reason. Even running yarn check shows that they can be deduped. You can run yarn --flat which forces everything to be at the top-level node modules and asks you to choose between version incompatibilities, but I haven't noticed a command that just fixes the yarn check output. yarn dedupe isn't available. There's https://github.com/atlassian/yarn-deduplicate which handles this a lot better.

Unfortunately, I'm not sure if there's anything we can do on our side.

[gkatsev]

Also, see relevant yarn issues yarnpkg/yarn#6070 and yarnpkg/yarn#3967. Unfortunately, there isn't anything more that we can do on our end.