Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

breaking change: Don't try to prepend https to module specifiers #3451

Merged
merged 1 commit into from Nov 10, 2023

Conversation

mstoykov
Copy link
Collaborator

@mstoykov mstoykov commented Nov 9, 2023

What?

Stop trying to prepend https:// to module specifiers that couldn't be parsed in other ways.

This also fixes tc39 tests and some archive ones that were depending on this functionality.

AFAIK all of those tests should've not been written the way they were to begin with - they just happened to work due to the previous behaviour.

Why?

This has been deprecated for years and never really made much sense, but made a bunch of the error messages way more convoluted.

Checklist

  • I have performed a self-review of my code.
  • I have added tests for my changes.
  • I have run linter locally (make lint) and all checks pass.
  • I have run tests locally (make tests) and all tests pass.
  • I have commented on my code, particularly in hard-to-understand areas.

Related PR(s)/Issue(s)

Closes #3287

This has been deprecated for years and never really made much sense, but
made a bunch of the error messages way more convoluted.

Closes #3287

This also fixes tc39 tests and some archive ones that were depending on
this functionality.

AFAIK all of those tests should've not been written the way they were to
begin with - they just happened to work due to the previous behaviour.
Copy link
Collaborator

@olegbespalov olegbespalov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe it's a good idea to modify the error message (mentioned inline). Otherwise LGTM 👍

func (n noSchemeRemoteModuleResolutionError) Unwrap() error {
return n.err
func (u unresolvableURLError) Error() string {
// TODO potentially add more things about what k6 supports if users report being confused.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's probably a good idea to provide the list of the supported moduleSpecifiers to give a user an understanding of how they look like

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I really don't like our messages being super huge. Which is why I prefer to err on the side of them being short then giving a lot of information that potentially won't be useful.

In this case explaining the modules can be absolute file paths, with or with file://, https:// urls, or relative paths (and what they will be relative to) + the k6/* stuff is way too much text. That arguably won't even help you enough.

I am somewhat okay with linking to the docs https://grafana.com/docs/k6/latest/using-k6/modules/, but even that seems a bit longish.

Especially as my expectation is that the most common case will be buffer or something similar from nodejs or npm.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cc @oleiade ^

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are we discussing this message?

The moduleSpecifier \"example.com/html\" couldn't be recognised as something k6 supports

How about something like 🤔

The module specifier \"example.com/html\" is unsupported. Supported module modifiers are `file://`, `https://`

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or even less, gaining from the context:

The module specifier \"example.com/html\" is unsupported. Supported are file:// and https://.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are we discussing this message?

Isn't this what you wanted? Or did I misunderstood?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was trying to address this:

I really don't like our messages being super huge. Which is why I prefer to err on the side of them being short then giving a lot of information that potentially won't be useful.

I mean, the message that we return right now (got it from tests):

The moduleSpecifier \"example.com/html\" couldn't be recognised as something k6 supports

And suggesting that we consider modifying it to something that contains examples:

The module specifier \"example.com/html\" is unsupported. Supported are file:// and https://.

Anyway, it was a non-blocking suggestion, so feel free to ignore it and merge as it is 👍

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This does not mention both relative module specifier and neither does k6/net/grpc for example

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've merged it for now - I would prefer to get some user feedback on this before doing something.

If you (or anyone else) disagree - please open an issue.

We can change the message fairly easy - even though it will need to be checked around in tests

@olegbespalov olegbespalov added the breaking change for PRs that need to be mentioned in the breaking changes section of the release notes label Nov 10, 2023
@mstoykov mstoykov merged commit 348aadd into master Nov 10, 2023
23 checks passed
@mstoykov mstoykov deleted the deprecatePrependingHTTPsToSpecifiers branch November 10, 2023 15:40
@mstoykov mstoykov added this to the v0.48.0 milestone Nov 10, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
breaking change for PRs that need to be mentioned in the breaking changes section of the release notes
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Remove trying to load remote modules by prepending https://
3 participants