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

Tests for extension lookups #215

Open
phated opened this issue Jun 3, 2020 · 4 comments
Open

Tests for extension lookups #215

phated opened this issue Jun 3, 2020 · 4 comments

Comments

@phated
Copy link
Member

phated commented Jun 3, 2020

While thinking about #214 (comment)

I realized I also needed to add the .mjs extension to the 1.x and 2.x release streams of interpret, but all the tests were passing for gulp-cli.

I think this is due to us using --gulpfile for all our tests. @sttk do you know a way to test for the extensions?

@sttk
Copy link
Contributor

sttk commented Jun 3, 2020

@phated Extension tests are executed in a Liftoff's test. That is test/lib/register_loader.js.
The explanation of the test is as follows:

  1. Creates loader mock for each extension. It returns a loading message with a loaded file name and the loader name.
  2. Sets a loader:success event handler to a sample Liftoff app, and verifies the loading message in the event handler.
  3. Executes registerLoader with extensions option which has only a pair of target extension and the loader mock.

@phated
Copy link
Member Author

phated commented Jun 3, 2020

@sttk with the completion of #214, a file with .mjs extension does not use the loaders as handled by liftoff because is uses import(gulpfilePath). That's why I think we need to include tests for loading by extension in this project.

@sttk
Copy link
Contributor

sttk commented Jun 4, 2020

@phated Sorry. I didn't look detail of #214, and I assumed that the dynamic import function was used like require with being associated with .mjs. But the merged way is better according to interpret#68, indeed.

@phated
Copy link
Member Author

phated commented Jun 10, 2020

@sttk I'm thinking about our APIs for the next major version and maybe rechoir can become an abstraction over require/import() like was added in #214 - it might even be able to handle "loader extensions" that the node.js team is working on for import

@phated phated added this to To do in v5 Oct 21, 2020
@phated phated removed this from To do in v5 Mar 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: No status
Development

No branches or pull requests

2 participants