-
-
Notifications
You must be signed in to change notification settings - Fork 503
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
Conversation
packages/craco/lib/config.js
Outdated
loaders: { | ||
'.ts': tsLoader, | ||
}, | ||
}); |
There was a problem hiding this comment.
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
?
There was a problem hiding this comment.
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 :)
There was a problem hiding this comment.
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
?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes go ahead. Thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done. ;)
Have you installed the extensions? The code should auto format on save to follow the repository code style. |
Please update the docs to indicate CRACO support TS files. |
If CRACO support TS file, should CRACO also export typings for it's hooks, plugins and utils? |
packages/craco/lib/paths.js
Outdated
} | ||
|
||
log("Found craco config file at: ", result.filepath); |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this 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.
packages/craco/lib/config.js
Outdated
loaders: { | ||
'.ts': tsLoader, | ||
}, | ||
}); |
There was a problem hiding this comment.
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/paths.js
Outdated
} | ||
|
||
log("Found craco config file at: ", result.filepath); |
There was a problem hiding this comment.
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.
Done
I'd prefer to leave it for another PR. It'd be nice, but I'm not familiar with the detail of all configs. |
I’d suggest using the definitelytyped repository for this, since it is easier than converting the entire projet to TS for now |
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 |
Merged, thank you @alvis :) Will release soon. |
Released in https://www.npmjs.com/package/@craco/craco/v/6.4.0! |
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 👀 |
@codex We are definitely interested! |
Great! I'll start chipping away at it and throw a PR up when I have a start, and work out some strategy things :) |
@alvis I have a few quick questions before I get too far in, where is best to contact you? |
sure. feel free to DM me on twitter |
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. |
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 inpackage.json
should you prefer it.If you prefer the old way that
cosmiconfig
inpackage.json
represents the path to the config file, it works as well.Fix #235 #290