Fix style modules not being resolved from iframe.html (#266)

[Dschungelabenteuer]

Fixes #266

See comment #266 (comment)

• Upgraded to Vite 2.8.5 to reproduce the issue
• Updated outdated CONTRIBUTING.md

[IanVS]

Thanks for digging into this! It sounds like vite is going to revert for now, and re-introduce this change into 2.9 (vitejs/vite#7136). So, let's hold off on this change for now, until things stabilize a bit. But this seems like a reasonable fix once they do make the change.

[Dschungelabenteuer]

@IanVS I've seen the discussion on Vite's Discord server, should I close this PR or do you want me to update it to include poyoho's implementation of the fix ?

[IanVS]

If you're up for using that approach, that would be great! Although, it would be nice if we can use native browser methods and avoid adding a dependency on 'url'. Thanks!

[Dschungelabenteuer]

Hey! Just gave it a try and it seems to be working fine! However, using the native URL API requires:

• adding "DOM" and "DOM.Iterable" to the tsconfig's lib property
• a valid URL (which /iframe.html is not), so my first idea was to mock a local file, but I'm not sure this is the best way to go

Any suggestions? See changes

[IanVS]

Thanks yet again! I think I need to apologize for sending you down the wrong track. I'm so used to working in the browser that sometimes I forget that most of this code runs in node. And I didn't realize that url is a native node module, so import { parse as parseUrl, URLSearchParams } from 'url'; isn't actually adding a dependency, but rather using the node module. If you used that approach, would it simplify things? Again, sorry for sending you down the wrong track there.

[Dschungelabenteuer]

Hey Ian! No worries, I should have been able to spot that myself 😄

Node URL module's parseUrl is however marked as deprecated since it's part of the legacy API. Using the WHATWG URL API - which mimics the browser URL API - still requires me to add a fake protocol for the URL to be valid. What would be your take on this?

[IanVS]

Ok, bummer. It feels weird to throw a file:// on the string just so we can parse it. What do you think about a simple id.split('?')? And then still using URLSearchParams to deal with the actual search string after the ?.

[Dschungelabenteuer]

Sounds fine to me, here you go 🤞

[IanVS]

It looks like another yarn install is needed, there seem to be changes to yarn.lock.

[IanVS]

Thanks!

[IanVS]

Released in 0.1.19.