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

Support more config file formats #334

Merged
merged 6 commits into from
Oct 21, 2021

Conversation

alvis
Copy link
Contributor

@alvis alvis commented Oct 14, 2021

This PR changes how the config file is located and parsed in order to support more file format such as crago.config.ts.

Under the hood, it uses cosmiconfig, a reliable and mature config parser, instead of the custom logic to handle the config in different formats.

As a side effect, it also supports cosmiconfig presented as an object in package.json should you prefer it.
If you prefer the old way that cosmiconfig in package.json represents the path to the config file, it works as well.

Fix #235 #290

loaders: {
'.ts': tsLoader,
},
});
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a specific reason why you call again cosmic config instead of using configFilePath ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because the config has to be loaded somehow, and they may not be necessarily .json or .js so that you can simply load with require, e.g. .ts or .yaml. cosmiconfig is used here again to load the config file found in paths.js. Hope this make sense :)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ahhh got it, thanks. Sorry for my ignorance I haven't, use cosmiconfig before.. since you don't specify searchPlaces here, how does cosmiconfig will behave?

Knowing this, I am not sure the code in paths.js to find the config file path is still relevant. Maybe move everything related to the config path in getConfigAsObject ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not ideal I admit. searchPlaces is omitted because the config is going to be loaded from configFilePath so having it here is just redunctant.

When I was implementing it, my first trial was moving everything to under getConfigAsObject, but I realise it will cause a compatibility issue that there is a chance the file path can be specified in package.json which is not picked up by cosmiconfig, so a separate logic is needed to handle that, hence I leave the path finding logic in paths.js, and the loading logic in config.js, even though cosmiconfig can handle both in one call.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not sure I follow here. Where would the config be loaded otherwise? When using a custom config path, the path is currently resolved in paths.js but even in your PR the actual config is always loaded in getConfigAsObject.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The problem is that cosmiconfig does recognize the config file path in package.json. It only consider the craco field in package.json as the actual content of the config. So another logic has to be in place to handle that.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, sorry I forgot your first reply which mention that you can't require a TS file. I get it now.

Though maybe paths.js could export a cosmicExplorer instance so it won't have to be configured twice?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It can be done but sharing a cosmiconfig instance would complicate the dependency graph, which I recommend not to. The current structure is fine, paths.js holds functions for finding the config file path, and config.js holds functions that parse the file.

I think the best solution is to move the logic of the config path finding to config.js and leave other path-related exports in paths.js. Then we won't have 2 cosmiconfig instances, and actually much cleaner. Shall I do that?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes go ahead. Thanks!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done. ;)

@patricklafrance
Copy link
Contributor

Have you installed the extensions? The code should auto format on save to follow the repository code style.

@patricklafrance
Copy link
Contributor

Please update the docs to indicate CRACO support TS files.

@patricklafrance
Copy link
Contributor

If CRACO support TS file, should CRACO also export typings for it's hooks, plugins and utils?

}

log("Found craco config file at: ", result.filepath);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You could move this log outside of the else to also log if the file config have been located from a path configured in package.json

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is actually already another log outside the else block
https://github.com/gsoft-inc/craco/blob/9e6bd9ed3d4d7861618c7b70048cca9ec1744b12/packages/craco/lib/paths.js#L57

So this line is actually unnecessary.

packages/craco/lib/config.js Show resolved Hide resolved
packages/craco/lib/paths.js Outdated Show resolved Hide resolved
Copy link
Contributor Author

@alvis alvis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

New changes committed as suggested.

loaders: {
'.ts': tsLoader,
},
});
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because the config has to be loaded somehow, and they may not be necessarily .json or .js so that you can simply load with require, e.g. .ts or .yaml. cosmiconfig is used here again to load the config file found in paths.js. Hope this make sense :)

packages/craco/lib/config.js Show resolved Hide resolved
}

log("Found craco config file at: ", result.filepath);
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is actually already another log outside the else block
https://github.com/gsoft-inc/craco/blob/9e6bd9ed3d4d7861618c7b70048cca9ec1744b12/packages/craco/lib/paths.js#L57

So this line is actually unnecessary.

@alvis
Copy link
Contributor Author

alvis commented Oct 18, 2021

Please update the docs to indicate CRACO support TS files.

Done

If CRACO support TS file, should CRACO also export typings for it's hooks, plugins and utils?

I'd prefer to leave it for another PR. It'd be nice, but I'm not familiar with the detail of all configs.
Need more time to prepare.

@alexasselin008
Copy link
Contributor

If CRACO support TS file, should CRACO also export typings for it's hooks, plugins and utils?

I’d suggest using the definitelytyped repository for this, since it is easier than converting the entire projet to TS for now

@alvis
Copy link
Contributor Author

alvis commented Oct 18, 2021

It’s not necessary to convert the whole project to ts just to provide a type file. It can by simply be done with an extra index.d.ts file.

@patricklafrance patricklafrance merged commit 0f59ef0 into dilanx:master Oct 21, 2021
@patricklafrance
Copy link
Contributor

Merged, thank you @alvis :) Will release soon.

@patricklafrance
Copy link
Contributor

@Codex-
Copy link
Contributor

Codex- commented Nov 8, 2021

It’s not necessary to convert the whole project to ts just to provide a type file. It can by simply be done with an extra index.d.ts file.

You can do it incrementally too, where some things are adapted to TS while still using the JS source in other parts.

I'd be happy to start on this in a PR if you'd be interested? I have a lot of experience with JS->TS projects 👀

@alvis
Copy link
Contributor Author

alvis commented Nov 9, 2021

@codex We are definitely interested!

@Codex-
Copy link
Contributor

Codex- commented Nov 9, 2021

Great! I'll start chipping away at it and throw a PR up when I have a start, and work out some strategy things :)

@Codex-
Copy link
Contributor

Codex- commented Nov 16, 2021

@alvis I have a few quick questions before I get too far in, where is best to contact you?

@alvis
Copy link
Contributor Author

alvis commented Nov 16, 2021

sure. feel free to DM me on twitter @AlvisHTTang or email alvis at hilbert dot space

@Codex-
Copy link
Contributor

Codex- commented Nov 18, 2021

Open your DM's on twitter ;)

Also the usage of the typescript config package here uses a no longer maintained package for managing the typescript parsing, which has a few issues and pr's open that resolve bugs I've run into lol so going to fork and publish a fixed version to remedy this.

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

Successfully merging this pull request may close these issues.

Be able to use TypeScript for / in craco.config.js
4 participants