-
Notifications
You must be signed in to change notification settings - Fork 44
Feature: Runtime loaders, transpilation at import time #96
Comments
I’m not sure the first example works - you have to require the register module before you’re able to require or run coffeescript. |
@ljharb I didn’t flesh it out, but the first example works if run via
|
@GeoffreyBooth to clarify, does this request require you to mutate the loader pipeline at runtime? If the loader needs to be declared somewhere outside of evaluation that does seem to fit this use case on a glance, but differs in workflow from your example (easier to analyze though). |
@bmeck from what I recall - loaders (declared via the CLI flag or package.json) are entirely sufficient in order to implement the feature requested here. I'm not saying they are the solution we should adopt necessarily. Just that importing CoffeeScript or TypeScript could work this way. |
Also, if such loaders (as declared via the CLI flag or package.json) existed, wouldn't that mean you could write a loader that allows mutating the loader pipeline at runtime? |
@bmeck I don’t think that necessarily needs to happen at runtime, if the advent of loaders creates a new phase of code to be executed before app code and dependencies are evaluated. I guess ideally we would support either scenario? But I’m not sure it makes a difference. It also depends on how loaders are defined and configured to be loaded. Currently, |
Just as we can do:
or
we should be able to achieve the equivalent in ESM, e.g.
import
a CoffeeScript file orimport
a JavaScript file that requires transpilation. References: CoffeeScript register,babel-register
.Use case 4. Related to #82.
The text was updated successfully, but these errors were encountered: