Tool is creating js file, but we use TS

[Alnipet]

After running steiger ./src --fix, the tool created index.js files, but we primarily use TypeScript. How can we reduce this?

[illright]

For now, no way, unfortunately, it is hardcoded. We will add this functionality in the next release!

[gwbaik9717]

I also experienced this issue while using steiger, so I'm interested in solving this issue. Could I be assiged to this issue?

The main difficulty here is accurately determining whether the user wants the publicAPI file in .js or .ts format. I think simply detecting the existence of .ts files in the repository is insufficient, as project could include both TypeScript and JavaScript files (especially considering TypeScript allows mixing). I came up with several ideas. Please let me know if there are any other solutions or plans.

1. Check for tsconfig.json in Root Directory

Determine if a tsconfig.json exists at the repository's root and check if the current path is included within its includes property.

Cons:

• The tsconfig.json may not necessarily be at the root specified by the user.
• Might be tricky to handle monorepo scenarios where multiple tsconfig.json files exist beyond the specified root.

2. Check by percentage of js and ts

Calculate the percentage of .ts files versus .js files within the given scope. If .ts files constitute a majority (e.g., over 50%), infer that .ts is preferred.

Cons:

• Could lead to incorrect assumptions if the percentage threshold doesn't reflect actual user intention.
• Users might have to manually adjust file extensions if prediction is incorrect.

3. Let user specify the extension in config

Although, this is the most clear, and easiest way to implement. Not sure this option is really valid.

[illright]

Certainly, thanks for volunteering! Let me quickly describe the vision I had for this feature.

There's a discussion about adding some kind of helper function system to Steiger that would have deep knowledge about the project. Internally these helpers are referred to as services. This is currently at the "idea" stage, it hasn't materialized yet, so don't worry too much about trying to match the exact interface proposed in this discussion, but it would be nice if you could keep it in mind in general. And we can always adjust it mid-way if we realize that a different architecture serves us better.

Another way to implement this is to implement auto-detection entirely inside the FSD plugin for now. Then, once we get the services set up, we can extract that logic.

Regarding the options you've described for actually detecting if the project uses TS or JS:

1. Check for tsconfig.json — great option, and I think we can rely on finding the nearest package.json and seeing if that folder has a tsconfig.json or a jsconfig.json. Monorepos are indeed a worthwhile consideration, so we might also want to check all parent folders for a tsconfig.json as well.
2. Check by percentage of js and ts — indeed, this might be a harder option to draw definitive conclusions from. I think the first option will already cover most cases that we're interested in, so we might not need an extra heuristic, and if it happens that we guessed wrong, we can always let the user override the inferred decision.
3. Let user specify the extension in config — this is certainly a good thing to have. Accidents happen, and we want to let the user override the decision if they do. However, I'm not sure how this option could look like. In another discussion (Configuration file format #53 (comment), see Example 2) I've envisioned settings like these being passed into the config of individual plugins, but that doesn't combine well with the idea of universal services that are decoupled from plugins and integrated into Steiger. On the other hand, the service's responsibility is only to detect if TypeScript is configured in the project, and it's the plugin that then makes a decision "therefore, we must output index.ts files". From that point of view, adding an option to the FSD plugin makes sense.

[gwbaik9717]

Thank you for the detailed explanation. Now I get the idea of service and how it should work.

For now, I'd implement auto-detection(figuring out JS or TS) logic entirely inside the FSD plugin. Then, once we have the services properly set up, we can extract that logic into a service.

Among 3 options, I’d try with:

1. Check for tsconfig.json — great option, and I think we can rely on finding the nearest package.json and seeing if that folder has a tsconfig.json or a jsconfig.json. Monorepos are indeed a worthwhile consideration, so we might also want to check all parent folders for a tsconfig.json as well.

For now the first option seems most likely to be reusable in the future. If users still provide feedback that it is not accurate enough, we might also consider adding a config to manually override the detection logic.