Add a codemod for transforming configs to the new format

[illright]

Closes #75

Create a steiger.config.js in the current directory and test the codemod with the following command:

pnpx jscodeshift -t https://raw.githubusercontent.com/feature-sliced/steiger/codemod/packages/steiger/migrations/convert-config-to-flat.js steiger.config.js

This command is huge, but the migration is so simple that I don't think our users will mind. I suggest writing this in the migration guide, although we will replace the branch name once this is merged.

Alternatively, you can test it here in the browser by running this in the terminal of StackBlitz:

npx jscodeshift --dry -p steiger.config.1.js

[illright]

@daniilsapa what do you think?

[daniilsapa]

@illright

Overall impression

Well done! This solution is extremely graceful and simple for a user, and yeah, a huge command should not be a problem at all as long as you can copy and paste it 😄

This is a very unexpected solution. I couldn't even imagine something like this. I never came across jscodeshift library and generally such a type of migration scripts/tasks, so it was my blind spot. I took some ideas into account. Thank you for that!

Questions

I have some questions that could potentially improve the solution

• Users who didn’t read the docs for the new config and just upgraded Steiger in their projects, what should we do for them? It sounds reasonable to throw an error with a link to the migration guide if the old config structure is detected.
• Is it available only for pnpx? I know that pnpm is gaining popularity nowadays. But looks like it’s still far from the most used package manager (if I’m not mistaken). So, can we also provide instructions for people who use npm and yarn?
• This is a very minor thing, it's more of a quibble. This may not be the last config migration, should we come up with a more specific name for the migration script?Something like transform-config.js => transform-config-to-flat.js?

Additional actions

We may need additional action items that would make the migration process smoother. Should we create additional issues for them or address them as part of the current one?

• Should we add the migration guide to README.md as part of this ticket?
• Should we add a description of the new config format to README.md and how to use it?

[daniilsapa]

Shouldn’t we also add an import for the fsd plugin and that …fsd.plugins.recommended line in the config definition? Because if we run the current migration, the config will have only the rules that were in the initial config. And since the main feature of the previous config was just to allow you to entirely disable a rule, the user most likely ends up with a config with all rules disabled and without rule definitions provided to Steiger.

[illright]

ah, yeah, good catch! we do need to add that

[daniilsapa]

Optional. We could check if the config is already in the new shape, just in case. But it seems like that would be a very rare edge case.

[illright]

If it already is, then it doesn't make sense for the user to run the migration, I think they'll know better. So let's just assume that there is something worth migrating

[illright]

Users who didn’t read the docs for the new config and just upgraded Steiger in their projects, what should we do for them? It sounds reasonable to throw an error with a link to the migration guide if the old config structure is detected.

Yes, I think that makes sense. We can add the message to the config validator

Is it available only for pnpx?

No, it was just an example. You can also do npx and yarn dlx in place of pnpx

So, can we also provide instructions for people who use npm and yarn?

Yes, let's do that

This is a very minor thing, it's more of a quibble. This may not be the last config migration, should we come up with a more specific name for the migration script?

Yeah, I agree that it would be nice. I'm not sure if it's best to have a descriptive name for this migration or simply call it by the version that it's migrating from (e.g. from-0.4.js). But I like your suggestion more, to be honest.

We may need additional action items that would make the migration process smoother. Should we create additional issues for them or address them as part of the current one?

I think we can make them in separate issues. The linter is currently not in a release-able state anyway, so it's fine to do it incrementally, I think

[illright]

@daniilsapa adjusted the codemod to also add the fsd.configs.recommended thing and renamed the file

[daniilsapa]

@illright
Thank you, perfetto 👌

[daniilsapa]

@illright
Also, I am thinking about creating a separate branch like develop to collect changes for a release. It looks like we should not merge everything to master because people can use the repository as a reference and docs, so we should not mislead them with features and docs that are not yet released. Adding a new branch allows us to collect changes there and merge them to master only when a release happens. What do you think?

[illright]

Yeah, I agree, I also thought that we should've developed in a branch. Since we have a bunch of unreleased work already, I think it's fine to keep merging to master, and we'll keep it in mind for future releases