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

Move to and support ESM #46

Merged
merged 10 commits into from
Feb 5, 2024
Merged

Move to and support ESM #46

merged 10 commits into from
Feb 5, 2024

Conversation

fmuellner
Copy link
Contributor

Add support for loading specs as modules, so specs can test modules without the need for dynamic imports.

With that in place, the code base itself can be ported to ESM, so do that as well.

This is the last release before 4.0 introduced major changes,
including a dependency on addEventListener()/removeEventLister().

Let's worry about that another day, it's already a worthy update.
globalThis was introduced in 1.64, which had only been released
a couple of months before the original switch.

There are good reasons to not depend on such a recent version,
however the release is now almost 4 years old, so the dependency
should be unproblematic.

This reverts commit ab197b0.
It's already provided by gjs nowadays, and has been for nearly
two years.
We'll need this eventually to port the code base to ESM. However
it doesn't hurt loading jasmine/runner as modules right now, and
it gives us access to toplevel await, which will help with the port.
When we move to modules, we will need more control over the
mainloop than we get from the legacy Mainloop module.

To prepare for that, let the Command module create its own
GLib.MainLoop, and expose it to the test that needs it.
Using a blocking run() call is dangerous, as it will prevent any
promises that were previously added to the implicit mainloop from
resolving.

gjs provides runAsync() overrides that avoid this issue, switch to
that for driving the mainloop.
While this is a bit artificial for specs that are imported as
scripts, it prepares us for dynamically importing specs as
modules, which is always asynchronous.
Add a new `--module` command line flag to import a spec as
module instead of a script. This allows creating specs that
test exports from modules without having to jump through hoops
to import everything dynamically.

(I would have gone with `-m` like gjs, but the parser currently
doesn't handle short options)
Some test depend on overriding the function, which will no longer
work when we move to ESM (where imports are always read-only).

Prepare for that by moving the function into an "indenter"
object, where it can still be modified after the ESM port.
Now that we support loading specs as modules, we can move away
from legacy imports without breaking our own test suite.

We still use a legacy import for the upstream jasmine library
and a test case of legacy imports, everything else is loaded
as module.
Copy link
Owner

@ptomato ptomato left a comment

Choose a reason for hiding this comment

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

Very thorough! Thanks for the modernization update.

@ptomato ptomato merged commit 034ac59 into ptomato:master Feb 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants