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

Let the user add more Rollup plugins and configure them differently #449

Open
caioquirino opened this issue Jan 29, 2022 · 6 comments
Open

Comments

@caioquirino
Copy link

caioquirino commented Jan 29, 2022

Hello,

I am trying to use a custom typescript transformer so I can make use of compile-time transformations, but I can't find a way to add it to the build. I haven't tested but I guess it won't read a rollup config file if I create it, right? (ref.: https://github.com/osdevisnot/klap/blob/master/src/plugins.js#L16)

I am happy to send a PR with a reference implementation, but before considering working on it, I would like to know if you have any suggestion of which approach to follow. For example:

  • Create a klap.config.js (or any name) file that supports hooking config changes (like pointcuts/hooks) in some points of the plugin (at least plugins.js file initially); OR
  • Find a way to use the rollup config file to override what's previously configured (Convention over configuration); OR
  • Just implement a basic support to typescript transformers and add it to klap object of package.json

Any other approach or suggestion is welcome :)

Thanks for the awesome project!

@osdevisnot
Copy link
Owner

👋 @caioquirino - can you say more about which custom transforms you are trying to use? The compile-time transformations for typescript are less supported in many bundlers such as esbuild and swc compared to babel transforms. It will be interesting to hear your use case.

@caioquirino
Copy link
Author

Hi @osdevisnot I am actually creating my own typescript transformer, that will read the entire project's AST looking up for a few specific decorators and writing extra files based on it (and removing them from runtime). So it's the same as any other Typescript transformer.

I am normally using ttypescript that patches tsc to include the transformers from tsconfig.json [read more: https://www.npmjs.com/package/ttypescript]

I know that rollup's typescript plugin supports transformers [https://www.npmjs.com/package/@rollup/plugin-typescript#transformers], I just can't find a way to configure it using Klap

@osdevisnot
Copy link
Owner

This is an interesting use case. Looks like tsc does not support configuration of transformers using tsconfig, which is why rollup plugin only accepts that using js api.

A similar use case was brought up before in #249.

Currently klap supports naive js api, something like this:

const { klap } = require("klap");
const isProd = process.env.NODE_ENV === "production";

const command = isProd ? "build" : "start";
const pkg = { name: "my-project-name", version: "5.4.0", };

(async () => {
  await klap(command, pkg);
})();

I think we should expand (potentially rework) this API to be able to configure klap for additional use cases.

@caioquirino
Copy link
Author

caioquirino commented Feb 5, 2022

That sounds like a good idea, I just feel like it's a little bit OP for something that is more like overriding minimal parts of klap's behaviour. So that's why even liking this programmable API approach nice, I feel like having the ability to manipulate smaller portions of the code (like a klap.config.ts) without having to instantiate klap manually could be a better approach.

In regards to the transformer issue, I've just found that ttypescript already support rollup (See here) so I was thinking about, for this specific case, integrating with ttypescript and changing klap config to be something more like:

package.json:

{
...
  "klap": {
    "typescript": {
      "enabled": true,
      "transformers": true
    } 
  }
}

Or:

package.json:

{
...
  "klap": {
    "usets": true
    "typescript": {
      "transformers": true
    } 
  }
}

Or any other format.

Another approach will be instead of using ttypescript is to manually implement a wrapper on top of rollup's @rollup/plugin-typescript plugin that abstracts to klap config the equivalent of what is already supported in tsconfig.json in ttypescript transform plugin:

export interface PluginConfig {
    /**
     * Path to transformer or transformer module name
     */
    transform?: string;

    /**
     * The optional name of the exported transform plugin in the transform module.
     */
    import?: string;

    /**
     * Plugin entry point format type, default is program
     */
    type?: 'program' | 'config' | 'checker' | 'raw' | 'compilerOptions';

    /**
     * Should transformer applied after all ones
     */
    after?: boolean;

    /**
     * Should transformer applied for d.ts files, supports from TS2.9
     */
    afterDeclarations?: boolean;
    /**
     * any other properties provided to the transformer as config argument
     * */
    [options: string]: any;
}

Examples: https://github.com/cevek/ttypescript#transformers

Another approach is to use ttypescript directly in this project and allow tsconfig.json to support transformers out-of-the-box

@caioquirino
Copy link
Author

We could even make ttypescript a peerDependency and override the typescript module only when it's available :)

@caioquirino
Copy link
Author

@osdevisnot I've tried in many ways to make ttypescript to work as an optional dependency, but when I've declared them as peerDependency and tried to import it only in the projects that uses klap with a tstransformer, but unfortunately when I did require('ttypescript'), it ended up throwing an ERR_MODULE_NOT_FOUND error...

So I am wondering if we could make this project to work with Typescript transformers out of the box, by just integrating it by default with ttypescript. What do you think? If you like it, I can just drop a PR here :)

Cheers!

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

2 participants