-
Notifications
You must be signed in to change notification settings - Fork 78
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
Custom Builds: Rename some source code files to separate words with dashes #833
Comments
@tmcconechy @deep7102 do you guys have any objections to the naming convention I described? |
As a note, we should definitely let LSF know about this change (and if we can think of anyone else) |
@duncsully @jake-harrington @awbuboltz |
@clepore @tmcconechy Thanks for the heads up! We can probably handle changes like this fairly easily. |
Descoping this for now |
Is your feature request related to a problem? Please describe.
This is an extension issue of #417. In order to fully automate custom builds, it's become necessary to create a hard guideline on matching a component's filename to its constructor. If the component is comprised of multiple words:
For example, consider the following:
Describe the solution you'd like
Firstly, there are some parts in the new build script being developed in #417 that should be reversed. A hard list of filename keys to dash-separated filenames is present that's currently handling the conversion. This is working for now, but the idea is to fully automate custom builds so that the file structure handles the order of the component files inside the build.
Next, we need to rename the following files to match the structure suggested above:
In addition to renaming the files, we need to examine any internal
import
/export
statements used on these files, and adjust them accordingly. We also need to allow the old nomenclature to access the new files (via mapping + dummy “function signatures”), but throw a deprecation warning during the build to notify the end user that these old names will not be accessible if they upgrade to the next major release (a future v5.0.0).Finally, test the build with some custom parameters calling some of these out directly (and the pre-built bundles described in #427, if applicable), and make sure everything builds correctly.
The text was updated successfully, but these errors were encountered: