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

Feature: suffixed generation #36

Open
conartist6 opened this issue Feb 16, 2022 · 3 comments
Open

Feature: suffixed generation #36

conartist6 opened this issue Feb 16, 2022 · 3 comments

Comments

@conartist6
Copy link
Collaborator

conartist6 commented Feb 16, 2022

This would be a default mode that would transform lib/foo.js to lib/foo.gen.js. This feature would prevent you needing to do something like renaming an existing foo.js to foo.src.js and would speed wholesale adoption.

@conartist6
Copy link
Collaborator Author

conartist6 commented Feb 16, 2022

I had been thinking I could bake some custom resolver logic (#35) into the code I generate, perhaps mangling import paths, but I'm realizing that such a setup would be too difficult to watch. Thus perhaps there is also no way to do this? I'll have to think about it some more.

@conartist6
Copy link
Collaborator Author

conartist6 commented Feb 20, 2022

I could just insert a suffix after an imported name but before its extension. For example:

import 'file';
import 'file.ts';
import 'file.test.ts';

would be transpiled to:

import 'file.gen';
import 'file.gen.ts';
import 'file.gen.test.ts';

This is a pure transform, and preserves the properties of the source. If the source was an esmodule with no resolver the output will still have that property. If the input did require a resolver to work, it still will.

@conartist6
Copy link
Collaborator Author

conartist6 commented Feb 20, 2022

Buuut for that to work, every single path has to get a .gen version. That's a lot to ask for, given that it's an extra thing on top of .ts => .js, and then would you also end up with .gen.ts and .gen.js?

It seems like this is a parallel solution to what I've been considering for re-entrant macros. In this version macro evaluation is written to the .gen file. In the re-entrant version the source itself is overwritten, and must be a polyglot which can execute at build time (where the macro reference will trigger build logic) as well as at runtime, where the macro module would export passthroughs.

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

No branches or pull requests

1 participant