Skip to content
New issue

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

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

Already on GitHub? # 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 post-v5 Mar 23, 2024
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
Status: No status
Development

No branches or pull requests

2 participants